Enterprise architecture: The missing link of business IT alignment

Business IT alignment is an issue most large enterprises grapple with. Normally there are separate organisational units for strategy and operations in enterprises. The business strategy unit formulates business strategy as a response to business drivers. Business leaders know, how to translate their business strategy into actionable items for business operations. That insured alignment of business operations with business strategy. IT strategy organisational unit formulates IT strategy, which needs to react to IT drivers in the market. IT organisations too are quite adept at translating IT strategy into actionable items for IT operations.

The problem arises when business strategy needs to cross over into world of IT operations for implementation. Or when IT strategy needs to cross into business operations for implementation. And more often than not, this is the case. This has been quite nicely described in an article [“Strategic Alignment: A model for organisational transformation through information technology,” in T. Kochan & M. Unseem, eds,Transforming Organisations, Oxford University Press, NY, 1992] by Henderson and Venkatraman, quite a few years back.

And each time the cross over happened, translation is required to and fro between these organisational units.Enterprise architecture function is on the cross-roads of these four arms of business, carrying out that translation. Since EA function is at the boundary of strategy and operations, it has to deal with both 'Micro' and 'Macro' at the same time. For the same reason it also has to deal with 'What' and 'How' at the same time. The key is to understand, that while EA is accountable for 'What' and 'Macro' part, it is responsible for 'How' and 'Micro' parts.

In lay persons terms, at strategic level the EAs are influencers. Their advise is accepted in making decisions. This role is bestowed upon them because they are thought to be capable of making things happen on the ground. The decision makers listen to EA about 'What' part because they expect EAs to take responsibility for the 'How' part.

Following this logic clarifies the duality of EA role.

• Strategizing and architecting at Macro level
• Consultancy and Governance at Micro level
  

While EAs want to spend more time on former than later, their wish may or may not be granted based on maturity of the IT organisation. And I am afraid, that is a sad fact of life in enterprise IT.

EA Governance

It has been a while since I posted on this blog. This discussion initiated by Todd is of some interest to me and got me motivated to post this entry.

I had spoken at Open Group Conference, about the same. My presentation can be seen here (subscription required).

My concise picture of EA governance is as below.


The governance function of EA can roughly be divided into three broad categories, viz. legislating, ensuring compliance to legislation during execution and adjudicating the non-compliance.

When people talk about governance they mainly talk about compliance and adjudication, as pointed out by Todd. But for me the most important piece of governance is legislation . That is - when principles, policies, standards and references, which defines the compliance framework, are set. A broader community participation at this stage and a feeling of belonging, improves the compliance and lessens need for adjudication. Otherwise it appears that EA group is pushing its own agenda on practitioner community and practitioners actively resist such a push. Which leads to a lot of adjudication, requiring lot of management attention.

I am not saying EA legislation needs to be a totally democratic process and must follow democratic norms. But at the same time, it should not appear to be totally autocratic top-down process, thrusting legislations down practitioner's throat. In large IT organisation critical projects get caught in adjudication cycle and EA gets bad press precisely because legislation has not taken on board various points of views.

That reminds me of the role of free press. If we compare EA governance to civic governance, the piece that is missing is 'Free Press' or a communications function. It is a bi-directional communication channel which informs practioners of strategist's intent and allows practitioner's to report back their experiences from trenches to strategists, so that strategies can be suitably altered.

The social media is a good candidate for fulfilling all these functions. It can be utilised to empower the practitioner community to participate in legislation process and can also function as 'Free Press' so that bi-diretional communicaiton can take place between strategists and practitioners.

Governance

Well I must share this experience on how effective governance control reduces to inefficient buerocratic controls.
This happened in a small airport, where I had gone to attend a conference.

While boarding the plane we were called in, by row numbers. Only hitch was, the plane being small, we were taken in a bus to the plane. So we were boarding the bus in sequence of our row numbers and not the plane. Once in the bus, people sat wherever they wanted to. Once they got out of the bus to board the plane, they were in random order. This defeated the whole purpose of boarding by row number.

Boarding plane in a order of row numbers makes it very efficient when passengers board the plane directly. But in case of boarding by bus, either the procedure needs to be changed to have desired effect or abandoned.

I think there is an important lesson in this, for people who design governance controls, for systems.

Centralised service delivery team

Typically in business IT world, budgeting and portfolio definition phase determines what business benefits should be targetted for in a given period and what is the maximum cost that can be paid to achieve those benefits. Business projects are then executed to deliver business benefits while minimizing cost and time to get those benefits. So notwithstanding the various benefits of building reusable services for enterprise, projects tend to do point solutions. Mainly because of these budget and time considerations.

In response to this situation, one of the best practices that has evolved in SOA implementations is to have a central team implementing services for business projects. This has been a good idea. It can address many of the governance challenges. Mostly because this central service team (lets call it services delivery team - SDT) is managed and governed by principles set by enterprise architects for SOA, rather than budget and cost considerations alone.
However there are a couple of challenges in putting this to practice.

• Having a right engagement between project team and this SDT is a big challenge. This engagement model breaks or makes the future of SOA, in the enterprise. It is vitally important to get this model right.
  
• Getting the composition of this SDT right is another challenge, that must be addressed.
  

Initially the SDT was set up as an island, which owned the services and its interfaces. The SDT utilised existing capabilities or whenever necessary got the capabilities built. The engagement between project team and the SDT, was mainly of an outsourcer - outsourcee type. The project team defined its requirement and threw those over to SDT. Which then worked out the interfaces (keeping in reusability in mind). Then further outsourced building of capability required (if ncessary), to teams maintaining the systems which might provide the capabilities. The SDT had only application architects and high level designers apart from project managers. So the role of this SDT had become that of a systems integration designers and SOA standard tools had become SI tools.

This mode of working had turned into a waterfall life-cycle model, partly because the way engagement worked. This started to add a lot of overheads in terms of time and effort to project estimates. At the same time, benefits were not immediately realised for projects. As a result project team started resisting this engagement model, which in turn was viewed as rejection of SOA by project teams (which it was not). When project managers are measured by budget and schedule compliance alone, it was natural for them to resist this engagement model which took away the control of deciding how much budget and schedule risk they can afford to take. So SDT too are facing problems.

I think a new co-sourced engagement model needs trying out. In this model, services delivery team works as part of project team, governed by same budget and schedule consideration. But they are also governed by SOA principles too. So when these two governance principles contradicted, comporomises were required to be made. These compromises were inevitably are made in favour of project. Rarely in case of strategic services, the compromises are made in favour of services. These compromises, in their wake, will leave what I call 'non-'services. Some of these non-services need to be refactored into services by a part of service delivery team, which gets its funding straight from CIO. This team has limited funding, hence could only turn so many non-services into services, resulting into a back-log. Over a period of time, size of back-log would give a fair understading of the costs involved in making tactical compromises against strategic imperatives. This model needs to run for some time, for its efficacy to be known. For this model to work, it would need strong SOA governance framework and a strong testing facility in place.

Any sharing of experience in this area is most welcome.