Is The Current EA Paradigm Right For Business Architecture?

In preparation for our next EA Forum, I have been doing a lot of reflecting lately about the state of EA and what it means as we move forward into business architecture. And frankly, I don’t like what I am seeing – or more accurately, I don’t like what I am thinking. It seems to me that we are stuck in an outdated – and I will go out on a limb here and say not very successful – paradigm. So what is a paradigm? In this case I am referring to our thinking paradigm – the model in our brains that structures the way we think about EA. Our paradigms represent the “box,” as in thinking inside the box. When we are thinking outside the box, we are essentially trying to create a new paradigm – or thinking model. Paradigms are very powerful. That is why it is so difficult to think out of the box for any extended period of time. Here are the six elements that I see very consistently in the thought patterns of EAs:

Governance – Mechanisms to approve EA designs and enforce adherence to the reference architecture at the project level.

Principles – Decision filters that both EA development and application decisions flow through.

Current state – A snapshot of current issues and technology baseline (often in significant detail).

Reference architecture – The body of work describing EA’s intent, organized in a framework, expressed in strategy, standards, patterns, guidelines, etc.

Target state – An idealized future state viewpoint describing how the organization desires to change the current state based on the current understanding of technology and architecture.

Solutions architecture – Application of principle compliant reference architecture to current problems in order to move the EA closer to the target state viewpoint.

So what’s the problem? We seem to adhere to this model even though it is at best only moderately successful. For example, most EAs have established a governance process, but very few describe it as being impactful. Almost all EA teams have a set of principles, but almost none actually live by them – they are more like a set of good intentions. And who has actually attained a reasonable facsimile of their target state?

But what is really nagging at me is this: Is this the best paradigm for creating a business architecture that business types will appreciate and engage with? Somehow I don’t think so. Now seems like the right time to step out of our boxes and think differently.

Comments

Considering that EA does a

Considering that EA does a great job in describing the “enterprise genotype” (a full nomenclature of enterprise artefacts or assets) and there are many techniques to evaluate the “enterprise phenotype” (a set of observable characteristics such as performance), then a _bridge_ between “enterprise genotype” and “enterprise phenotype” is still missing.

I think that executable models of relationships between artefacts (with the use of BPM and SOA) can be a good foundation for such a bridge.

Thanks,
AS

Everything needs to change with technology

To me, it seems as if most of the EA's are older, more conservative and understand the world of standalone systems with a slight nod toward virtualization. Throw on a smattering of cloud technologies, SaaS and NoSQL, and their brains just burst and smolder.

I may be an older EA, but I constantly read, try new programming languages and set up cloud machines just so I can keep up. Things really do need to change in the EA world - but I think it's more about expanding ideas and understanding and embracing new technologies and techniques rather than the current framework.

Start from enterprise, not IT

One of the main problems with the usual EA paradigm (as seen in most existing EA frameworks such as TOGAF and SAP) is that it places IT as either the sole centre or the endpoint of all EA activity. The result is that in TOGAF, for example, 'Business Architecture' is only peripherally about 'the business of the business', but more like a random grab-bag for 'anything not-IT that might impact IT'. Yes, of course IT is significant, but no matter how much IT-folks would like to delude themselves as to their importance, it's not the centre of the business world - and until we get clear on that fact, EA is going nowhere.

To take each of your points in turn:

Governance – EA is intensely political: we will guarantee failure if we believe that we can 'enforce' our architectural opinions on everyone else. We stand a much better chance once we realise that negotiation and discussion and arbitration are the real core of the work; the main role of a reference-architecture is as an agreed means to manage architectural and technical risk. Ultimately, architecture is everyone's responsibility - not solely that of people with 'architect' in their job-title.

Principles – These again are mechanisms to manage opportunity and risk. Ultimately all principles need to anchor back to the enterprise-vision.

Current state – Fundamental principle: _there is no state_. Everything is in flux; 'now' ceases to be 'now' and becomes another 'now' before we even have a chance to blink. he notion of 'current state' is useful, but we should be careful to avoid deluding ourselves or anyone else into thinking that it actually represents anything static.

Reference architecture – "The body of work describing EA’s intent, organized in a framework, expressed in strategy, standards, patterns, guidelines, etc." Agreed - yet it needs to be understood in the same sense as the military concept of 'Commander's Intent', a guidance, a direction, rather than anything that should or even can be enforced.

Target state – Once again, _there is no state_. At the minimum, a 'target architecture' must identify which parts are expected to remain stable (e.g. large billing-systems) and which are likely to be volatile (anything impacted by rapid-changing technology and/or social context). It is all too easy to create an 'idealized' model that bears no resemblance to the dynamic messiness of the real world at all.

Solutions architecture – There's a lot more to EA than IT solutions-architecture... (And many of the 'solutions' needed in an EA may involve little or no IT at all - such as the disaster-recovery/business-continuity architecture to operate whilst IT-systems are out of action.) To take just one point, many if not most business-issues are 'wicked-problems', to which there is no 'solution' as such. The attempts to foist IT delusions of 'control' into areas that by definition cannot be controlled - such as the majority of business-processes - has been an expensive disaster in almost every case (IT-centric 'business process reengineering', for example). Only by thinking wider than IT do we have any chance of creating 'solutions' that might actually work. Yes, there's a lot of IT-related detail that needs to be addressed: but that comes _after_ clarity on the overall architecture, not before!

If we instead go back to first-principles, three points seem to stand out:

1. All of architecture really comes down to a single idea: that things work better when they work together.

2. Most people seem to be obsessed by efficiency, but what we're really after is effectiveness - 'efficient on purpose', in a dynamic, ever-changing business context - hence we need first to be clear on what that purpose is.

3. The ultimate anchor for the business is a single phrase (the 'vision', in the ISO9000 quality-system standard) that provides a valued common reference-point for everyone in the business and the business-context (market, broader community etc).

Enterprise-architecture is literally 'the architecture of the enterprise' as a whole - not solely 'the architecture of the enterprise-IT'. That point, perhaps, should be the real core of any new paradigm for enterprise-architecture?

Tom is right on the money...as usual

I have to agree with Tom. Specifically, with respect to the reality that architectural governance, principles and guidelines cannot be enforced, nor should they necessarily be.

Accepting that the purpose of EA is to aid in the continual redesign of the business, maximising effectiveness in the pursuit of the corporate vision, then the mechanisms ascribed to EA (governance, principles etc), are merely levers which are used to that end. They are attempts to constrain behaviour and structure to try and steer the organisation in the desired direction. Ironically, rigidly trying to enforce these constraints in all cases fails to accept the reality that circumstances (typically externally forced) change. Understandably, the desire for strict enforcement reflects a fear that failure of adherance will lead to an erosion of focus and ultimate failure to achieve the strategic vision. EA's often view themselves as the only true "keepers of the strategic flame".

At the end of the day, it is the responsibility of the executive to steer the organisation towards the vision. The PEAF (Pragmatic Enterprise Architecture Framework) concept of "Enterprise Debt" is a mechanism that allows for flexible EA boundaries (over the short term) while maintaining the tension required to keep heading in the "strategic" direction over the long term. Additionally, it does so without attempting to strip responsibility for such decisions from the executive.

Combining an IT-centric view of the world with a mistaken need for total control is a sure path to EA irrelevance.

Maybe the term is wrong

I think one of the major stumbling blocks with EA is the term - Enterprise. Enterprise seems to accept the notion that an organisation - and we typically refer to business organisations when we talk about enterprise in the context of EA - is homogeneous, unified in thought and deed and therefore capable of rationalisation. While elements of EA - such as IT - can be seen in a homogeneous fashion, other factors are more intransigent, more subject to change and therefore more difficult to accurately map and track.

This "business" view of the world, while it pays the salary for many of us, I think misses the point: organisations are typically comprised of multiple communities that are more heterogeneous than homogeneous in their day to day interactions on behalf the umbrella "enterprise". Sometimes such differences are small, other times they are pronounced. For organisations that form consortia, are part of complex supply and value chains or exist in quasi-symbiotic relationships with others it is right in their faces.

Obviously, the more dynamic organisation shapes and forms can be rationalised, reduced to a semi-homogenised form and this used as the basis for some of the machinations that EA favours, as noted in this blog and as commented on by Tom Graves. This works to an extent but does not really deal with the heart of the matter, that organisations themselves are internally evolving at changing at multiple levels, at different rates and within different cycles.

In a recent Gartner research paper on panarchy (http://www.gartner.com/DisplayDocument?doc_cd=209754&ref=g_BETAnoreg), Nick Gall makes the following recommendation:

"For hyperconnected enterprises in a volatile world, the primary goal can no longer be to simply protect and sustain the status quo for as long as possible. The primary goal must shift to understanding cycles of minor and major disruption and then "panarchitecting" how best to detect, respond to and, ultimately, renew them."

I would take that one stage further and note that such approaches must also be applied within the context of the organisation itself, to see how the natural forces at work across multiple communities within the enterprise can also be to drive a cycle of internal self renewal. To paraphrase Jeff Scott, this is the box thinking outside of itself and something that needs further exploration of what I would describe as Community Architecture or Community Design & Evolution. It is not just external events that shape an organisation and therefore EA needs to expand to cover the within as well as the without.

Current EA paradigm states the obvious

I think the "current EA paradigm" states the obvious. In fact, anything we achieve collectively in a company has to consider these same elements: Governance, Principles to guide decisions, existing and desirable states according to strategy and roadmapping, and projects (solutions) that implement it.
We already know it. We need no TOGAF to tell us that.
Is there anything EA specific in these elements? No. That is why EA deliveries depend so much on the deliverer. Do we have a framework that ensures repeatability, predictability...? This is what we need besides a general IT development process (TOGAF) and analytical thinking method (Zachman).
Adrian @ www.enterprise-architecture-matters.co.uk

Current EA Paradigm.

This is a real problem. For a number of years now, the divide between EntArch and BizArch has been growing. When I introduced business architecture at a fortune 500 several years ago -from concept to practice- as a member of that companies EA, I faced a traditional EA group fixed on your above mentioned practices. Not only were they battling agile sofware development practices, but now they got to battle with one of their own, my fledgling BizArch team.

For the purposes of adaptive and agile, responsive business architectures, centralization is a problem, especially highly governed, over-regulated centralization. This form of dictation presupposes highly predictable futures which have, over and again, shown not to be so predictable. The dynamic elements of complexity, ambiguity and unpredictability dictate the future.

In order to thrive in this kind of environment, an organization needs a degree - perhaps significant degree - of decentralizaion with a high degree of interdependence. Decentralization allows the parts of a business to grow and adapt as required rather than as told where interdepenence realizes the collective nature of the work.

Approaching the development of architectures (and businesses) in this manner improves adaptability and fitness as non-optimal centers can search for their own optimums in their own pursuit of excellence while still recognizing their interdependent nature. This approach has been shown to improve overall stability and adaptability.

This leads to serious problems with EA as "enterprise" solutions tend to inhibit the very adaptability required in this model of modern business.

Ugly realities

There's something we rarely touch on with this topic overall. Frankly it is a primary component left out of most frameworks (or theories or philosophies). The reality is that businesses, as extensions of human beings, don't always fit into the paradigms that we dream up. Yes it may be the optimal operational model for an enterprise, but people don't adhere to or seem to act in optimal or even rational modes. If a corporate environment is a microcosm of human interactions focused on achieving some set of objectives in order to make a profit, shouldn't a framework that purports to govern those activities involve some sort of social element? I don't know that existing 'governance' components of our frameworks are sufficient.

I don't know what the solution is, but we seem to be stuck in a mode of dictating how people process and technology ought to operate. At best we have control of the last in that list and influence over the middle one. At worst we are beset by problems in all three areas with little or no influence over any of them. But at the end of the day, we make very little effort to analyze, understand and incorporate the human factor in our architectures. I'm going beyond RACI charts and project management/ERP items. I'm talking about understanding the size, scope and nature of our social interactions as employees of an enterprise, understanding how they relate to process and technology and somehow incorporating them into a truly enterprise architecture.

Our technology has an architecture. Our business has an architecture. We're lacking a human architecture. Without it, I'm not sure how we hope to understand the motivations, interests, competitions, politics, etc that so often negatively impact our grand architectures.

How about a social architectural layer?

As simple as possible but not simpler

Chris touches upon very valid points above.

A major source of failure is not only the lack of recognition that enterprise architecture is about more than IT, as Tom has been arguing over and over.

There is also a lack of understanding that enterprise “systems”, by the inclusion of people, are of quite a different nature than IT systems. Most “Enterprise Architects” have an IT background and are primarily familiar with IT systems. And that shows off.

Today’s enterprise systems are neither mechanical nor deterministic as their IT counterparts or industrial age predecessors. Today’s enterprise “systems” are really quite different animals to tame. Nevertheless most enterprise architecture approaches continue to support the attempt of trying to mechanize enterprises to the extreme: people act in roles, are part of formal hierarchy, in their acting execute processes, etc. In a society that has passed beyond the industrial age, in which understanding and wisdom have become much more important and prevalent than ordinary know-how, this simply contributes no longer to a sustainable reality.

Unfortunately the failure of enterprise architecture is also that of a wider failure, one also that Tom already points to. It is actually a sign of the times, of a society that is obsessed with efficiently operating (the money machine) but only narrowly interested in reflecting whether strategy and structure for operation is effective and sustainable within the bigger context. This way enterprise architecture suffers twice.

It is time to start thinking about the enterprises as systems with models that are “as simple as possible but not simpler”, by anyone involved, not only architects.

90 percent of teams adopting

90 percent of teams adopting any method, framework, paradigm will fail to achieve promised benefit. The potential value of any newish paradigm is marketed off the success achieved by only 10 percent of adopters. Perhaps our paradigms are not the determining cause of our success or failure - perhaps its the capability of the people we pur in our teams. What paradigm is that?

I am not worried about EA's capability

I agree that a large percentage of EA teams fail to achieve the promised benefit but I see the paradigm problem the other way around. The EAs I have encountered over the past 10 years of consulting have been bright, hard working, and very committed. They are for the most part highly capable individuals. The issue is they are aimed in the wrong direction. The current set of EA paradigms tends to focus EAs on what I would call "architectural engineering" rather than architectural design. True, part of the problem is that we are attracting individuals that are drawn to that view of the world. I think what we need is a paradigm that focuses on collaboration rather than governance, strategy rather than principles, and business insight and perspective instead of an idealized future state blueprint. Then EA would attract a different set of architects and help the current EAs see a different future for themselves.

EA's obsession with efficiency

Hi everyone,

This comment set is a bit of a who's who of EA. You have some real though leaders in your following Jeff!

I'd like to pick up on two of the comments:

Tom G "Most people seem to be obsessed by efficiency, but what we're really after is effectiveness"

As always Tom has been insightful and this is something that I have been reflecting on. I've noticed that nearly all of the EA literature and frameworks come from or refer to manufacturing businesses. Case studies and examples are always about manufacturing and rarely about service providers or knowledge-centric businesses. They are nearly always about commerce and much less often about government or non-profit where motibvation and accountability create very different cultures. This is a failing of us as the EA comunity and a reflection of the maturity of this discupline.

Kris M "Unfortunately the failure of enterprise architecture is also that of a wider failure ... a society that obsessed with efficiently operating but narrowly interested in reflecting whether strategy and structure ... effective and sustainable."

Another enlightening comment from Kris that observes that through human history there has been a percieved need to grow, espeically in capitalist economies. As we are facing the first real tglobal threat to human existence there is an slow realisation occuring that we have grown enough and that balance in the system will need to become our primary driver . This is both in a planetary sense and also an industrial sense. We are getting to the point where people in the west are looking for work life balance. It is starting to become realistic for some people rather than asking for more salary they are asking for the same salary with less work (e.g. 9 day fortnight)

All of the above reflects on the weakness of curent EA paradigms being generally an extension of industrial engineering where as Nigel Green puts it in his book Lost in Translation (great book btw) "users want a system that works the way they do, which is often amenable to change and supports learning. The IT specialist, on the other hand, seeks a high degree of certainty and actionable rules that can be configured or encoded." Efficient but not necessariy efective.

Efficiency versus Effectiveness

Right on Alex - EAs are challenged a number of ways here. 1. What we in IT continually hear from the business is efficiency, efficiency, efficiency. But what they really want is for us to be more effective at solving their problems. Since they don't know what we need to do to be effective - and they shouldn't have to know, that is our job - they push on cost - something they understand. 2. IT is over managed and under led. What the organization needs from IT is strategic leadership - what it gets is tactical management. EAs are uniquely positioned to deliver on more effective solutions but their own management team doesn't encouraged them to move in that direction. 3. In many cases the wrong guys are in EA and this is one of the places where I think a paradigm shift would help. First, the majority of EAs are technical experts. That's great for technical engineering problems but many just don't have the interest in attacking business, strategy, and organizational issues. Second, many are attracted to EA because they want to make a difference but fail to realize that one makes a difference through influence - not authority and control.

The question I am struggling with is: How do we recreate the EA paradigm so that we attract the right players, recast EA as a strategy, innovation, and organizational effectiveness function, and move it into a true leadership role. I would love to hear everyone's ideas.

Rebranding Needed

Some great comments above. Jeff, we do need to recreate the EA paradigm and rebrand it as there is way too much baggage associated with "EA". The need for EA has never been greater with Cloud and SOA to name a few of the technolgy drivers and the competitive global market and need for innovation being some the business drivers. To make it work will require a new breed of leadership (not traditional IT types) who can sell the concept, make it a true partnership with the business and deliver real results.
The single biggest gap that I have seen in EA programs is not building out the business architecture roles. Without this it is understandable that what is produced is technically focused white papers, standards, efficency opportunities and heavy handed governance. The business controls strategy and funding and EA programs will need to change and gain credibility to get a seat at the strategy and innovation table. The journey continues:-)