Do you have a buy versus build architectural principle? If so, why do you have so many developers (or armies of consultant programmers) in your IT organization? While some of them may be developing web apps or functional extensions to purchased applications, for the most part they are doing integration development. They are probably building fine-grained web services to access data resources, or coarse-grained services that provide some useful business function, or process orchestration solutions to automate long-running business processes, or data migration in support of application modernization, or data synchronization in support of a data warehouse or master data management solution. The list goes on. In short, you are an integration shop.
My advice therefore is to focus your efforts on standards for interfaces, integration systems, data exchanges, and loose coupling. If you do it well, and stick with the strategy, over time you will have a huge impact on the performance, throughput, and agility (ability of IT to adapt to business needs) of the system-of-systems across your enterprise.
You may be familiar with the idiom “tilting at windmills” which is about the futility of attacking imaginary enemies. Some of the windwills in IT architecture include:
- Technology wars like Unix/Windows/Linux or .NET vs. Java vs. C#
- Developing an Enterprise Data Model (unless you’re building a data warehouse, but then it’s not an enterprise data model it is an application data model with the application being a DWH)
- Fighting the business over selection of an application vendor (as long as the vendor conforms to the integration standards)
If you accept the premise that the largest system is your Enterprise Integration System (as I wrote about last month in The Biggest Application Is Not What You Think It Is), then that is ultimately where you should be investing your time and energy.
Some enemies are real – like the integration hairball for example. The hairball sucks up maintenance dollars, adds risk and cost to projects, and is generally a drag on making any kind of systems change. Kind of like swimming through molasses. A better solution is to replace the hairball and all the unique point-to-point interfaces with a Data Integration Hub. The DIH not only eliminates the hairball over time, but it helps to decouple systems and thereby accelerate the pace of change in IT and ultimately the competitiveness of the enterprise.
You can’t win all the battles, and you don’t have the time and energy to fight every battle – so choose carefully. I’d love to hear from some of you architects. Which windmills do you think are real and worth taking a stand on in your organization?