EA politics

Is Enterprise Architecture a breeding ground for politics? As with any human activities and relationships, there is politics, but to what degree?

Some time ago, someone, reviewing my book, pointed out that there is no section on the politics of Enterprise Architecture (EA). I was not convinced then that there is politics, or at least, no more than in any other complex human undertaking. Nevertheless, EA spans business and technology knowledge domains and crosses many internal organization boundaries and, as a result, it is prone to politics. Now, that I am closer to publish an updated version of the book, I started looking at politics in relation to EA. To find out, I searched the web, looking for a definition:

"Social relations involving authority or power". 

"Politics is the process and method of making decisions for groups… While politics operates, all decisions are provisional!" 

"Although it generally applies to governments, politics is also observed in all human group interactions including corporate, academic, and religious".

And about office politics: "social alliances often formed between colleagues of similar interests who may team up against other perceived competitors".

However, while formally correct, is this really what the suggestion was about? What about the day to day usage of the word. Since, this time, I could not find anything much on the web (?), I dared define it myself (with all the possible drawbacks) as consisting of:

Promises, frequently made by politicians before elections, seldom enacted 

The impossibility to get straight answers from politicians when asking even the simplest of questions

High ground moral stances driven, in reality, by self interest

On a positive note, politicians must be energetic, skillful negotiators and decision makers to balance legitimate and conflicting interests of many parties. But what has all this to do with an Enterprise Architecture development and the Enterprise Architect? Enterprise Architecture and its promoters, myself included, promise a lot, but does it, or do we deliver? 

Don't we sometimes assume the same moral high but safe ground when over selling the concept for the higher good of the Enterprise? The reality is that the typical EA development outcomes, more often than not, do not significantly change the structure of the organization or convey the much-touted agility to the firm. In other words, EA may not deliver to the promise. The truth is that the EA development can easily end up in various forms and shapes in the absence of an agreed definition or framework, since there is too much variability in terms of scope and deliveries. That is why US government mandated reference models to set expectations and be able to assemble the resulting artifacts in a coherent framework. A proper EA framework, reference model and process will fix this.

I heard rumours that IT fears the business reaction when confronting them with EA/SOA programs. Therefore, IT avoids naming it, substituting it instead with a discourse on benefits. This sounds a bit like the politician, avoiding a sensitive topic, with a convoluted response. But isn't this happening because EA and SOA have been grossly over hyped and over sold even before they were properly defined and scoped? Or, is it the "nervousness" of business, created by so many recent prophecies of "do EA/SOA or die"? 

In reacting to this technology push, business does not contest the potential benefits but requires a business case and careful planning to justify and roadmap the move from the current, not badly yielding "status quo", to the revolutionary services based business (e.g. SOA) since the costs of the business disruption, might brake rather than make the business. 

The divide between business and IT is a major source of debate in the Enterprise world and I would dare say, a breeding ground for politics. Business and IT speak different languages. They might look like two political parties engaged in a quest for the same holy grail, the budget. However, is it not the organization of the company and its governance, failing to align business and IT functions to a common strategy and objectives?

And is it not the Enterprise Architecture now charged with aligning the IT to business, that is, in effect, cross the political divide with the Enterprise Architect is in the lead? 

The conclusions I can draw so far: an Enterprise Architect has to be politically astute to justify EA/SOA, argue the business case, rally support from stakeholders, keep management informed and optimistic, do the work and survive the process! 

...

The EA is commended because of the state of high entropy of the Enterprise: high complexity, poor availability and understanding induced by years of patching, point solutions, silo operation, organic growth, mergers and a growing divide between business and IT. Business needs to change and compete faster and faster while IT can no longer cope with mending the legacy of the past, unwiring the architecture "hair ball" and integrating technology generations from various eras, including the mainframes, the dinosaurs of IT. 

Business got tired of the exotic IT acronyms like WS, SOAP, REST, UDDI, WSDL, mashups, AJAX, ESB, BPM, BPEL, XML, UML, TOGAF… some badged 2.0 now (and technology is changing at an exponential rate these days - Ray Kurtzweil's law-, so it is getting worse). IT is not talking either about Value Chain, business models, process improvement, Six Sigma, regulation, customer satisfaction, Balanced Scorecard, SWOT, KPIs, NPV, payback, the terms the business understands. 

But, on the other hand, is business providing, in the first place, the process architecture, business information and vocabulary necessary for IT to comprehend and align the technology? 

The net result of all this is the great divide and an increasingly high charged atmosphere progressing towards a blame culture.

And the solution is the EA which ought to mend all the evils of the Enterprise, to cure the silo culture and patch the divide between IT and business In a nutshell, EA becomes the ground of the already existing political battle but, at the same time, the tool to mediate the political divide. 

While the EA encompasses alignment of business, strategy, technology and people, the IT takes the driving role without business and top management support. How is this supposed to happen? After all, more than half of the EA is not IT, i.e. business processes (how), strategy (why), data (what), organization (who)… In fact without a strong business leadership and participation, EA would lack political support and fail to deliver on its promise since IT alone cannot specify SOA business services, improve processes, determine usefulness of data... Over-hype has already placed EA and SOA at the top of the curve where the credibility is not sustained yet by realisations. The IT history lessons would not concur to support the EA far-reaching claims; the result is that the business doubts it! 

In this phase, the best you can do is be convincing i.e. gain support for the EA business case which you should be expressed in financial terms. Spend energy to rally critical stakeholders' support in business and top management. Involve them by planning adequate EA artifacts, in response to their requests, explaining what is in it for them. 

Without critical business input, the resulting IT only Enterprise Architecture would provide mainly the Applications, Infrastructure and may be Data architecture, which is frequently the case, but not sufficient for releasing of all goods of the EA: process improvement, agility, strategic planning etc. The business people will have little reason to consult it, the word spreads, and, progressively, the EA losses its momentum everywhere. The loop is closed now. The business was right to doubt it, after all.

...

Thinking in many Enterprises is tactical, at best, firefighting would better express the facts. The EA is strategic, a long term transformation accepted because of its strategy promise but its acceptance may become a lip service only, with its execution ever postponed to cope with tactical crisis. In truth, EA will compete for resources with many other activities which have not been included in the EA scope, in the 1st place. 

Supposing the EA development moves slow and is delayed, it will be generating a lot more tactical-strategic conflicts: business people need solutions yesterday, the market cannot wait and the EA will provide the feature who knows when! Tactical projects are approved then and have to co-exist and compete for resources with the EA program. The chance to accomplish the implementation of EA slips away.

There is no easy solution to this except delivery on time and fit for purpose. To reassure everybody have a clear, simple plan in place that you are confident you can deliver to. You probably have one single try. Deliver often, iteratively, emphasize value returned. Prioritise business needs, deal with the EA trigger cause first and deliver what the stakeholders requested. This is a program, so business process discovery projects will have probably to be executed in parallel to Applications, Infrastructure, Data architectures and other streams. Then add views as DW/BI, Content Management, procurement processes, network architecture etc stakeholders typically need. With a delivery plan in front, people can wait, if they trust you. Otherwise, tactical projects win.

There are EA execution mistakes: ignoring important stakeholders, not communicating properly or enough in simple clear definitions and messages, not consulting relevant people, not referencing and recognizing contributions, to name a few, provoking the syndrome of "not invented here" i.e. you have not consulted us, where did this come from"?

From your side, lack of EA development experience and poor definition of scope and deliveries not fit for purpose, i.e. (typically large documents with poor focus) can increasingly deteriorate credibility as the development process is stalled by unusable outputs and by disputes about if and how the artifacts are to be used.

Define an EA vocabulary, for both business and IT to use, and Frequent Asked Questions to avoid confusion and display the progress dashboard on the Web for transparency.

...

Enterprise knowledge is locked in people's minds. To release this collective wisdom you need negotiation skills, "selling not telling", to move to a culture of recognition and reward. Otherwise the information you may get for the EA may be of little value. 

The EA team must have a vast knowledge spanning business, IT and people issues and be socially and politically astute. Selection of the proper EA team constitutes the major risk in this development. This team will not only have to develop the EA properly, but will have to explain it in simple terms everybody can understand, and then gracefully deploy EA compliance controls in all major business processes without meeting resistance.

EA is perceived as a threat since, in reducing duplication in process, platforms and projects it creates redundancies, it brings change. Change Management (CM) becomes essential in the Enterprise transformation execution process since people can and will resist, will do partisan fighting since, after all, their job is at stake for no grander purpose. CM has to work along to provide a path forward for all affected by the migration process to expose the greater good, to motivate. Early preparation is essential to avoid problems.

Agile processes with frequent deliveries and wide consultations will help make the process transparent and as such, accountable. Bottlenecks have to be quickly discovered and eliminated. Observe EA inhibitors since they could stop your EA development early, and find ways to conquer them from the beginning.

The governance team has to be properly chosen to reflect all interests and has to have enough authority to make it happen. Roles and responsibilities have to be well designed to avoid overlaps generating confusion and conflicts and, in the end, politics. Work as a team is crucial as the domain and span of activities is much too large.

Accountability and empowerment, recognition and award as company values will pave the way to progressive success in eliminating a culture of politics.

After the first few deliveries, it is important to police all other development work, install EA compliance controls (checkpoints) in all relevant business processes, provide training and easy access. Otherwise your EA may be ignored, forgotten.

...

Why should there be EA politics in the first place? Because EA is a complex, long term human activity, demanding cooperation of many parties and expensive skilled resources. And politics is all about human interaction and competition. Because EA is challenging the status quo of the Enterprise by altering its normal course for the sake of the future: EA is about strategic planning which inherently collides with the tactical thinking and action of Today - perhaps because the change is coming today at tactical speeds. 

What are the drivers for EA? From a business perspective, it is the inflexibility, slow change and high costs of IT. From and IT perspective it is the lack of business process and requirements clarity, inherited obsolete technologies and the tangled IT spaghetti architecture. For now, no politics, everyone wishes the change.

From this point on, the politics escort EA along its life cycle. Political pre-conditions:

Businesses are already organized in silos which means politics already exist inside and between silos

The existing great divide between business and IT, makes any new IT initiative a political issue

At concept, where the main debate is about the meaning and definition of EA.

The scope agreement in this phase, if any, can determine if a true EA is going to be developed, an IT only architecture, an ITIL implementation or other. This dispute hits the balance between the tactical and strategic thinking and it is crucial as the benefits diminish at the same rate with the scope reduction. And hence "nay" sayers.

At initiation, the argument is about To Do or not To Do Enterprise Architecture, argument most often not supported by compelling business cases. The EA benefits, like for many other architecture developments, are hard to quantify in a business case but it should be done on a best effort basis. There is also the hype or overhype which may animate the IT and annoy the business. Hence business prefers not to hear about it while the IT world is shouting. 

How many times SOA was presented as a technology, while the reality is that it deeply affects the way your business works? The business under direct market pressure cannot afford to play with technology trials. This may explain the half-hearted buy in from business the reluctance to hear about EA or SOA. 

Furthermore the EA is a threat to "status quo" we all like.

The design is a milestone for the EA since a poor design would leave its internal customers baffled not able to understand what to implement. The classical example is the "tome" delivery. A such another kind of politics of "passing the buck" to the next team. 

There is no Business Architecture in the first place to guide the Technology architecture. The EA would be the common ground where business and IT meet and talk the same language. But the IT would have to drive the business architecture which is not perceived as necessary by business, hence reluctance and scepticism. Here is where, without communication and sanction from the top the EA will fail in politics.

True, the initial confusion starts with the world of EA design frameworks, which was compared to a jungle. The deliberation about frameworks can be bitter. A mixture of them is usually the answer but there are acerbic camps. Then the Enterprise knowledge is locked in people's minds. The ability to extract that information may be a political art. Not consulting the relevant groups breeds the "not invented here" syndrome. 

The execution, if defective, trailing for too long or not solving the immediate business pains, will surely spawn heated arguments. There is little tolerance for long programs with uncertain results. Slow, delayed development, revive the tactics to deploy tactical. Lack of transparency in execution, rumours taint the atmosphere.

The EA governance will most certainly create political debate again if it does not involve all concerned parties.

At utilisation: Make sure EA is not ignored, forgotten or considered a dead weight because you have not implemented architecture controls, check points in business processes. And some good practices:

Define clear EA and scope

Ensure business and management support from the beginning

Prioritise business needs, deal with the EA trigger cause first and deliver what was requested, listen to your stakeholders

Observe potential EA roadblocks from the very start

Define an EA vocabulary and Frequent Asked Questions to avoid confusion and display the progress dashboard on the Web for transparency. 

Select a quality EA team quality since it is the major risk; the EA team must have a vast knowledge spanning business, IT and people issues and be socially and politically astute; introduce EA accountability, recognition and rewards

Employ agile processes with frequent deliveries and wide consultations which will help make the process transparent and as such, accountable. Bottlenecks have to be quickly discovered and eliminated

Police development work, install EA compliance controls (checkpoints) in all relevant business processes, provide training and easy access.