Integration is a business issue (or rather, it should be)
Despite what most consultants and IT-manager are propagating, it is my strong believe that EAI projects should be seen as business projects. The problem lies in getting corporate management to agree on that matter...
So how would you go about achieving just that goal? Relatively simple; just explain to them how their organisation would create a strategic advantage by executing the project. There is no simple one-fits-all solution to this, it is always context bound. That said, let's look at an example scenario.
Imagine for while, a company that delivers ready made components for a product, which it builds from self-made components and components bought from other companies. To make it more real, let's suppose this was a company delivering aircraft doors to specification, using doorhandles from a third party.
These production processes tend to go on for many years, since planes are usually in production for decades. It being a high-yield business, it is important for the aircarft constructor to get the doors at the latest possible time, but never too late so as not to delay the delivery of the aircraft.
The goals of timely delivery are untill now met by maintaing constant contact between the door supplier and the aircraft constructor. The door supplier would do the same with the door handle supplier and so on. We can see a nice supply chain building here, and in reality the complexity will be much greater of course!
In this particular case a very simple sales pitch aws put together to give the doorbuilder a competitive edge, and the bottom line was to create an automated online, realtime insight into the supply chain. This would be achieved by extending the doorbuilders IT systems to enable the aircarft constructor to check delivery schedules online, including the delivery schedules from the doorhandler company.
The ultimate result would be a fully transparent supply chain, since it
was foreseen that the suppliers of the doorbuilders company would be updating their delivery schedules online as well. It did not take management a long time to realize the strategic advantage of this integration project, and it was no big problem in getting the budget from them either.
Just imagine what it would have taken to approach this as an IT only project; as you know, and will propably have experienced, it is not easy to get a budget in that case.
This is naturally a simple example, dated also, but it goes to show that their is allways a possibillity of getting management buy-in for your integration projects.
Next time, I will write some more on an EAI maturity model and growth path I have drawn up.
Regards,
Jan Kopmels
Despite what most consultants and IT-manager are propagating, it is my strong believe that EAI projects should be seen as business projects. The problem lies in getting corporate management to agree on that matter...
So how would you go about achieving just that goal? Relatively simple; just explain to them how their organisation would create a strategic advantage by executing the project. There is no simple one-fits-all solution to this, it is always context bound. That said, let's look at an example scenario.
Imagine for while, a company that delivers ready made components for a product, which it builds from self-made components and components bought from other companies. To make it more real, let's suppose this was a company delivering aircraft doors to specification, using doorhandles from a third party.
These production processes tend to go on for many years, since planes are usually in production for decades. It being a high-yield business, it is important for the aircarft constructor to get the doors at the latest possible time, but never too late so as not to delay the delivery of the aircraft.
The goals of timely delivery are untill now met by maintaing constant contact between the door supplier and the aircraft constructor. The door supplier would do the same with the door handle supplier and so on. We can see a nice supply chain building here, and in reality the complexity will be much greater of course!
In this particular case a very simple sales pitch aws put together to give the doorbuilder a competitive edge, and the bottom line was to create an automated online, realtime insight into the supply chain. This would be achieved by extending the doorbuilders IT systems to enable the aircarft constructor to check delivery schedules online, including the delivery schedules from the doorhandler company.
The ultimate result would be a fully transparent supply chain, since it
was foreseen that the suppliers of the doorbuilders company would be updating their delivery schedules online as well. It did not take management a long time to realize the strategic advantage of this integration project, and it was no big problem in getting the budget from them either.
Just imagine what it would have taken to approach this as an IT only project; as you know, and will propably have experienced, it is not easy to get a budget in that case.
This is naturally a simple example, dated also, but it goes to show that their is allways a possibillity of getting management buy-in for your integration projects.
Next time, I will write some more on an EAI maturity model and growth path I have drawn up.
Regards,
Jan Kopmels
posted by Jan Kopmels at 12:07 AM
1 Comments:
Integration is indeed a business issue and not an IT one.
The problem lies within the higher management, because they delegate the problem down to some project leader which gets a bag of money to develop one application. With this approach the company will have one project leader and one bag of money for each application. Those project leaders will not work together, like sharing information, developing reusable components, etc. They all have one excel sheet with some figures to prove that their project is on time and within budget.
Before I describe my solution, I will first describe the problem area.
Image we have a company which has some mainframe systems, some applications running J2EE or .Net, some external third party IT systems and they will deliver this functionality on the Internet for their customers and Intranet for their own internal processes.
We will have a lot of duplicate functionality if we are developing with the original approach. Each project will create their own validation code, subsystem adapters, etc.
My opinion is not to give some project leader a bag of money, but to create specialized teams (do one thing and do it well) which will be a transparent supply chain with centralized business service which can be reused. Those teams will have a delivery responsibility to their customers; the other teams (work hard, play hard). We will create a specialized team for each subsystem, so one for each mainframe system, one for each J2EE or .Net system and one for each external third party IT system. We will also create one specialized team which is responsible for making the functionality of those subsystems available as centralized business services. People who sell ‘Knowledge Flambé’ call this an Enterprise Service Bus. And we will create a team for developing the Internet/Intranet applications which we use the centralized business services.
The advantage of this approach is that each team has clear responsibilities and is able to train their people to create a specialized team. With this you can better use the knowledge of you team, because they are working in just one problem and not at four or five like working in a project with the old approach (result: better quality). Another advantage of this approach is that you we able to think better about your business processes and make them available as a business service for the rest of the company (result: better reusability). With those results we will have lesser bugs and a better time to market (sorry, for the buzzword). More advantages are there, but I have more to do today, like working in a project using the old approach.
Koen Molkenboer
Post a Comment
<< Home