Let me tell you a fictitious story. Ok, so it's not fictitious, but I swear I've never seen it happen where *I* work.
The salesmen are pushing customers hard. Sell. Sell. Sell. Gotta make that comission and feed the kids!
What did you say? If we just customize the Worbler you will sign? SOLD!!
At some random point in time down the road, a business analyst sees the contract.
Ah! To customize the worbler, we will need to integrate these two systems.
The Business Analyst writes up the requirements and calls the two Solution Architects.
You guys need to integrate to make this customized Worbler work. Go do it. Here are the requirements.
The two solution architects argue for a while. One is closely aligned to database work. He wants to integrate the two solutions at the database. The other has most of his logic pulled out into a set of cohesive webservices. He wants to integrate using Xml and Webservices.
They bicker for quite a while until one caves in--which one isn't really important. They quickly make the arrangement and pass the requirements and design off to their team to implement.
What's wrong with the above scenario?
No one is there to champion the long-term health of the enterprise. We have four stakeholders involved:
- The Customer wants his functionality (as of yesterday).
- The Business Analyst wants his requirements met and the project completed.
- Each of the 2 Solution Architect wants his preferred method of integration (database vs webservices) used.
You'll notice that no one is there to champion the long-term cause of the business.
Why does it matter?
In our fictitious example above, the enterprise had 20 systems. The same scenario played out over and over again during a multi-year period. The solution architects designed the best solution they knew to integrate each time the requirements came up.
Guess what? That company just paid for 190 integration projects!!
Since no one was there to watch out for the interests of the business, each project implemented a point-to-point integration project. They did the easiest and cheapest thing 190 times and spent a crapload of shareholder money in the process.
You might wonder where I got the 190 figure from. It comes from a little math formula which tells us the number of connections between nodes in a system, (n^2 - n) / 2. For only 3 systems, there are only 3 lines of communication. For 10 systems, there are 45 lines of communication. For 20 systems, there are 190 lines of communication.
The Lesson
When dealing with boundaries between systems, you need someone to champion for the enterprise. It needs to be someone who understands the long-term implications of architecture, and it needs to be someone who doesn't already have a horse in the race. This is the role of an Enterprise Architect.