Teamwork
Since a few weeks now, I’m part of a team of 4 responsible for the realisation of an ESB with a customer of Ordina. Working in a team is new to me, but all reactions are positive and I’ve been invited to join the project for the period of a year. I haven’t decided yet whether I’m going to stay onboard for the entire period, it depends on my own wishes (which I haven’t clarified yet).
I’ve become a huge fan of Lorem Ipsum to fill yet unfilled space in a document. Yes, unnecessary, yes geeky. 🙂
Behold the lovely project-template and the magnificent lipsum-text. I like!
To display some semi-random geeky humor-related stuff: Dilbert!
Why realise a service bus? What’s the business case? You can’t “realise a service bus”, you’re always tackling a bigger problem to which a service bus could – although not likely, in my experience – be a solution – or you should anyway. So what’s the problem being tackled?
Is it a full-time project? And is it a 4-hour-per-trip project? 🙂
And nice to know you don’t consider me and Nick a team and ACAS a project 😛
Yes, that has to be the reason why I like babbling to you that much. The irresistible combination of sharp-tongued criticism and the playful joy of letting my own words bite me in the butt. 😀
The BC is the realization of a complete information-infrastructure and application portfolio (COTS + some homebrew) to replace the existing stuff. Infrastructure, applications, business-processes, it all is replaced with new ones. Simultaneously. You can imagine the issues. 😉
All applications (9 in total) are bound together through the ESB which is functioning like a broker with common tasks being offered to the applications as services. Picture a star-network with the ESB in the middle, and all* communication going through the bus.
*all, with 2 exceptions due to load.
The intended results are as usual: better products, faster delivery, prepared for the future.
All I can say about it is the following: the project is huge, very interesting, slightly megalomaniac and really prestigious for all parties involved. Flagship-stuff.
Ouch. Those are the fun projects to have 🙂 probably being championed by a sponsor high up in the organization who still thinks IT is the answer to everything but doesn’t have a clue about it (like our secretary of state De Jager…). slightly risky although there is álways a factor to point to in such a huge project. I have a megalomaniac like that on one of my own projects – it’s fun trying to squeeze your own vision and project approach in with a project when the sponsor doesn’t start on equal terms and visions with you 🙂
The problem with flagships is easy to spot. How many flagships do you know for any other reason than being shot, utterly destroyed, totally obliterated, never having left the harbour, or sinking just before finding new land (dear, dear Columbus and his Nina…)?
What tech stack are you using? I know Oracle’s bus isn’t intended to handle huge dataloads – they have a special product for that one.
All butt-biting aside, it’s fun to know you’re an integral part of a big – huge – project. You’re playing techarchitect I suppose from what you’re defining here? Do please, for the love of god, think of defining your principles and starting points that you use to make your choices. It makes the whole process much more accountable: get support for your arguments and you’re in the clear.
Great advice there, and I’m presumably (yet not defined or formally checked) in a technical architectural role. I know vague, don’t ask. 😉
We’ve been busy scoping and making others responsible for stuff we don’t want to do for the entire time up until today (and presumably for some time to come) so we’ve got that one pretty much covered. 😛 We’re continuously checking and rechecking the needs and requirements as set by the client plus getting approval signatures wherever we can, just to cover ourselves in case something goes wrong. The proposal Ordina sent in after the RFP spoke of a success rate of about 20%, which has been acknowledged and accepted by the client. Lucky us.
BTW: we are going to use the Oracle ESB suite, and this is where things start to get nice: Oracle themselves are heavily involved. Not only as software supplier but also as sub-contractor. I’m guessing no worries there. 😉
Oracle involved? That’s strange. Ask them about Oracle Data Integrator. It’s what they’ve been positioning as their high-load platform recently, positioning the ESB as the routing & events solution mostly. Although that’s 11g material mostly, making it mostly a end-2008 or early-2009 playground. Still, it should be acknowledged if you’re building a platform for the future on Oracle software. Then again, I’m not that deep into the technical stuff and I suppose some of your colleagues – or you yourself, although I doubt that – are.
I’ll try to remember calling you tonight as I forgot last night. Crashed on the couch and mostly forgot everything else then… 🙂
After consulting my colleagues, it has become apparent ODI exists as a plan-b tool when the ESB cannot cope with the loads it is confronted with. ODI is thus only utilized/implemented/bought when applicable.
Furthermore, 11g is stell beta, while the organization is only willing to migrate to 10g as they are doing so themselves at this moment. Supporting 2 versions is too much for them, and is to be avoided at nearly all costs.
Oh well, it’s their choice.