Like many midsize companies, my organization realized at a certain point that its IT systems were becoming a major cost burden that needed controlling. We had around 1,000 applications, mostly owned by business units, a few hundred of which were substantially hand-crafted open-source developments, and two to three dozen that were multi-million pound investments.
The absence of any systematic architectural planning had created the all too familiar spaghetti-like situation which was difficult to sustain, and even more difficult to change. So the organization decided to create the role of Enterprise Architect, and appointed yours truly.
Since I had no previous Enterprise Architecture experience, I started doing research. The only book I found compelling was Enterprise Architecture As Strategy, but it required a high level of organizational maturity and significant buy-in from senior management. Similarly, I was dismayed to find Enterprise Architecture frameworks were complex and highly theoretical in nature. Even a call with a leading IT Advisory group only turned up a few nuggets, such as standard job descriptions for the Enterprise Architecture “team” (of which I was the only member.
My conclusion was traditional Enterprise Architecture frameworks require a serious commitment in terms of time and resources, which, in my case, were in short supply. But this wasn’t a reason to give up. The problems were evident, and many could be tackled by using educated common sense.
Initially, some effort was put in to understanding our current situation – enough to confirm the suspicion that we had an awful lot of isolated, stove-pipe applications with significant amounts of duplicate functionality.
To address the problem going forward, it was clear we were going to require a framework to guide our decision making, so I developed and published a set of architectural principles in a succinct four page document. Many of these eight principles were obvious – for example, use of enterprise solutions and technology standards, and re-use to avoid duplication and technical complexity.
But I then had to look at how we could put in an enabling environment to prevent those principles from remaining just words on paper. My conclusion was that we needed what we called an Applications Integration Platform to provide a set of common Service-Oriented Architecture services (Enterprise Service Bus, Service Registry and API Management, Authentication, etc) that would allow applications to be built with a shared set of common services accessing common data sources.
The aim from a technical perspective was to remove many of the underlying complexities normally built into each new application, and, from a business perspective, to reduce the cost and shorten the time to market of new applications.
To avoid a lengthy formal procurement process for the Applications Integration Platform, which could have taken a year in our organization, I performed a paper-based evaluation of open source platforms and chose one which, in addition to meeting our requirements, had the benefit of a formal support option.
Sign up for CIO Asia eNewsletters.