Some years ago I interviewed a CIO of a Fortune 500 IT vendor as part of an Integration Improvement project. His responses helped shape the goals and roadmap of the project, as business drivers and goals should always be taken into account in how one models the architecture and integration space. The interview gives a great view of IT management business drivers in the integration space. Company identifying information has been removed.
Question: How is integration?
-- Almost everyone at our company is an expert on Information Systems.
-- Our culture - everyone (department/division) believes their own numbers and requirements and doesn't believe anyone else's. Words like "mutual understanding" or "common terminology" didn't exist in the past.
- The reason there is no real enterprise integration because of how the company is running. Each unit built their own systems.
- The other units came to IT and said "buy this for us or build this for us, exactly per our requirements".
- Result, we have a large number of systems, majority home grown because building to our own specs was (considered) easier (in the past.)
Today we want to do the opposite. We want to create best practices and show to our customers "this is the best way to manage your business". To implement the best practice by picking the best packages (vendor software) that does those processes. (Best of breed approach - but the business idea behind it is best-of-breed to implement specific target business processes, some of which may be offered as solutions to customers.)
Now we are not "developing" but coming with a solution. But there is no one company that can bring the best solutions across all the lines of business. Therefore we understand that we'll need multiple vendors to provide all the needs.
We have a variety of lines of business. And there are different requirements in the different lines. So we have to come up with the best practices for each business unit...and they don't want to bother with integration (they don't see integration are part of their business goals - interoperating with other business units is not a focus for them). But they want us (IT) to build them one integrated view (across business units) of what's going on.
The result - different packages (that we didn’t build), each from a different vendor. Some according to standards, some not [because sometimes the best solutions aren't standards compliant) and sometimes even different solutions from the same vendor are operating per different standards (a result of many vendor portfolios being built via acquisition).
The expectation is to build a common integration layer that can integrate the various tools from the different vendors….AND provide a common process view and data view that we can analyze.
...and the cost of maintaining this should go down (in comparison to today) and should continue to decrease.
So adding new systems shouldn't create a linear growth in the cost. The company wants to measure IT...what is the cost according to what it should have been by adding more and more systems? And how does it compare to the current cost of today. They want us to reduce the real maintenance cost of today even though we're adding systems and capabilities.
They want IT costs NOT TO GROW but provide additional capabilities (do more, spend the same).
How to do it? Some kind of miracle (we have to find).
Question: What's the time frame to meet these goals.
Answer: No one expects us to come up with all of this, this year. But what they do expect is new systems work should be meeting the new goals.
ROI - people have to commit to improved project impact by showing over 5 years how costs in particular areas (for example integration support) will be reduced. In order to make decisions we need to quantify everything as best as possible...even knowing some are assumptions that you can't really quantify at this stage. So we need to build a strict ROI but we can, for example, quantify values of agility (an example I provided).
Because we're in the process of replacing many older systems, we can easily quantify major ROI returns much faster. (Meaning switching old systems to a new method might have a very long ROI period, but incorporating the new method with the implementation of a new system eliminates a "change over" cost as that's already part of the old system replacement cost.)
After we make a decision on best internal practices, the cost of new projects will automatically include the overhead of doing the interface according to the right method/pattern/etc. And it's our job to convince the managers that it has the long term value in reducing the maintenance costs.
Question: Cultural drivers?
Answer: Our main driver, being able to respond to customers needs and changing business. As a company operating in technology fields, the technology is constantly changing as is the business environment.
We must be able to integrate new things very fast, and do so without destabilizing existing systems or significantly increasing support costs.
Today the capabilities we (IT) give to the company are very low. We're not meeting the business requirements of new functionality the business demands. There is a long back log of features the business has requested that we can't provide within our available budget and resources. We need to be able to delivery fast and agile.