A pragmatic approach to Enterprise Architecture

A pragmatic approach to Enterprise Architecture

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.

I used that support, and also brought in external technical expertise to accelerate the build, and within six months we had a stable platform and had built several prototype use cases on top of it. For example, we demonstrated a simple travel request, approval and reporting app which used the platform to access, process  and update the equivalent planning, financial and reporting data held in three different and difficult to program systems.

Having built the platform, the next question was how to get buy-in from the business units owning the major IT systems, especially those used to working independently. For this, I realized we needed external expertise again, both to help us through the decision making process and to provide a neutral facilitator for some tough conversations, so I recruited an independent Enterprise Architect to review the architecture of our major technical systems and recommend a way forward.

We approached that exercise as a series of workshops over a one week period, inviting business units to multiple sessions. In this way, we obtained a better understanding of the business concerns and identified some unexpected priorities, such as the urgent need for a Reference Data Management system.

Business units also understood, when faced with the gory details of the spaghetti-like mess that had been created, the need for change and a new approach. The resulting report received universal support and planning for implementation is now underway.

As one business representative said, “the lack of a coherent IT architecture was a hard nut to crack and one the organization had failed to do for more than 20 years.” Instead of trying to tackle this through the political channel of management committees or complex architectural frameworks, we have instead managed to shine the light so compellingly on the problem that the organization could do nothing but support the change.  

One result of this process is that IT has gained credibility within the organization and is being looked at to drive further change.

Does this mean I can now dust off my copy of Enterprise Architecture As Strategy or sign-up for training in TOGAF or the Zachman framework? No, instead we plan to move on, and, having resolved some of the key aspects of the back-office corporate IT services, we have set up a Digital Strategy team to build on the platform approach and to promote more innovative and strategic use of IT Field projects in developing countries. All of which means that IT can make a greater contribution in the organization’s mission to end hunger in the world.  

And to me, this Digital Strategy work is just another way of doing Enterprise Architecture, but in a way the business understands and supports, and without scaring them with all those IT acronyms.

Whimpenny is the Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations (FAO). The views expressed here are those of the author and do not necessarily reflect the views of the Food and Agriculture Organization of the United Nations (FAO).

IDG Insider

PREVIOUS ARTICLE

«Need work-life balance? These IT jobs can be a good place to look

NEXT ARTICLE

5G will need small cells, so Nokia is sending in the drones»

Add Your Comment

Most Recent Comments

Resource Center

  • /view_company_report/775/aruba-networks
  • /view_company_report/419/splunk

Poll

Crowdfunding: Viable alternative to VC funding or glorified marketing?