Dion Hinchcliffe's Next-Generation Enterprises

Dion Hinchcliffe

Fixing Enterprise Architecture: Balancing the Forces of Change in the Modern Organization

Vote 0 Votes

There's been a lot of discussion in IT circles and online lately about the future of enterprise architecture. As the highest level and most strategic technical function in most organizations, good enterprise architecture is vital to the vision, capability, and healthy operation of today's modern organization. As any IT architect will happily tell you, in today's 21st century enterprise, technology is used pervasively to enable, automate, streamline, and transform business processes of every description. At its very best, enterprise architecture provides the bright lines that articulate the full range of possibilities for a business, even describing how to go about getting there.

But there's long been something fairly unsatisfying about the relationship that enterprise architecture has had with the business side of most organizations. Recently there's a growing realization that traditional enterprise architecture as its often practiced today might be broken in some important way. What might be wrong and how to fix it are the questions du jour.

Examining Today's Common Enterprise Architecture Pitfalls

This morning here on ebizQ Brenda Michelson examined the latest list of enterprise architecture pitfalls as part of the larger discussion that's taking place these days about EA. With organizations such as Gartner proclaiming the advent of newer approaches such as emergent architecture and reporting out the aforementioned pitfalls, there's a lot of change in the air at the moment. A recent piece in ComputerWorld interviewing the deputy CIO of NASA immediately noted that enterprise architecture is "far more difficult to properly implement than most IT professionals realize". Richard Veryard contributed to the discussion today as well, noting that the trouble with these diagnoses is that while essentially correct (perhaps even obvious) they aren't by themselves actionable information and therefore can't help lead to better outcomes.

In other words, problems aren't solutions and EA definitely seems to have some problems to solve. In particular I'd argue that there are two primary reasons for most of the reported woes. One is that EA is apparently quite difficult to do well and the second is its overly centralized nature. In this view, which I'll for now call a "next generation" perspective of enterprise architecture, there must be more agents responsible for enterprise architecture that are in a position to do it properly, carry it out effectively throughout an organization, and are connected deeply with the business, both locally and widely. And because EA is increasingly seen as a core business activity (even if it's all too often not) as well as a technical discipline, the current situation of relatively enforced -- though unfortunately quite often naturally occurring -- separation has caused many of the problems that we're seeing today reported as pitfalls (having the wrong architects, not engaging business people, etc.)


Looked at this way, enterprise architecture is thus the responsibility of almost everyone in an organization that makes longer-term decisions (business or technical), especially when they are captured and represented in a IT system somewhere. But EA is too difficult for this to be responsibly done by anyone but capable enterprise architects, right? This then is perhaps crucial to understanding the problem.

Reexamining The Fundamentals

One key way in which civilization (and technology) advances is when things that were formerly difficult become easier to do. Concepts like abstraction, encapsulation, componentization, dependency management, etc. made it possible for software architecture to evolve to a point where it could be intellectually mastered and directed at a systems of systems (i.e. enterprise-wide) level. Key to this whole discussion seems to be the truism that software architectures are most successful when certain constraints are left open. These can be well-defined interfaces or the use of open standards, or anything in which a distinct and important point of flexibility is explicitly left open for use and change down the road when more information is available or when the situation changes.

Identifying these points where choice might be needed and making it possible is one of the most important and central activities in software architecture. This is even more true of its cosmopolitan big brother, enterprise architecture. In fact, I've argued in the past that the simplest possible definition of the job of a technical architect is "to put off key design constraints until the last responsible moment." The magic, of course, lies in knowing what should be locked down and what should be less constrained.

We are perhaps learning to what degree that enterprises and the resources within them have properties and abilities that can't be declarative prescribed or controlled in a straightforward manner. From my personal experience, I'd say the more constraints and controls that are imposed architecturally, in general, the poorer the outcomes. From my research in the past on how SOA and Web 2.0 are actually two sides of the same coin, it's apparent that we have a lot to learn from very large yet loosely cooperating architectures that seem to work so successfully on systems of systems like the Internet. This is particularly true when the technical architecture is the business, a convergence that's only going to increase in our organizations, not decrease. The key point here is the excessive architectural constraints diminishes available options, limits flexibility, and ultimately reduces outcomes. The more control you assert over a system, the less it will be able to do. The converse is true as well.

The fact is that enterprise architects are often looked at these days as the police, invoking "governance" as a mandate to do things that sound right on the face of them: introduce standardization, reduce duplication and waste, and improve the levels of integration and connectivity between systems. If if these outcomes are desirable (and they can be), several important things are missing. One is that in any large system, local actors will often (but not always) have a more concrete and clearer understand of local situations and how to take advantage of them. Top-down enterprise architecture often fails to incorporate this or tries -- rightly or wrongly, and too often the latter -- to adapt the local conditions to a more unified, global environment. Second is enterprise architecture's generally poor role as a direct enabler of business opportunities and improvements. Again, at its best, good EA certainly does this. But average EA is about imposing familiar structure and patterns, not inspired and insightful business solutions.

So unfortunately, in this way, far too often enterprise architectural involvement actually creates a bottleneck for business activities and becomes an active dampener on what is possible. It also tends to be carried out on a schedule and with requirements that aren't aligned well with the local actors. Consequently, it's rare to see a business unit run to IT and ask for more enterprise architects to help them with their challenges.

A New Vision for Enterprise Architecture

There are two ways to go about solving these problems. One is to push even more control and oversight up into the purview of enterprise architecture to "get it right". In this way we can give EA efforts more resources so they can be more responsive and spend more time in the trenches. However, I think most people would agree that's not going to be the right answer. The other is to make enterprise architecture far more autonomous, distributed, and loosely coupled than it is today. That is, spread the wealth, greatly increase architectural capacity (via decentralization), loosen up the constraints, and try to guide the outcomes taking place at the edge of the organization.

A large number of good things can come from this relatively simple (though far from consequence free) act. (Like any good two-edged object challenges will also result.) In practical terms, this means moving to a practice of enterprise architecture focused more on delivering choice and options (a consumption-oriented view, as in people wanting to consume what you have or can do because it will help them) and one that is free of as many essential constraints as possible (practically, only truly essential ones like security, legal requirements, and the most critical business needs.)

The Implications of "Next-Generation" Enterprise Architecture

What does all this mean in practical terms? How does it change the picture of enterprise architecture in businesses today? Well, there are a number of significant and far ranging implications, some that are surprising but that I mostly find encouraging. From what is apparent at this point, they are:

  • Highly pliable software platforms that are more customizable, on-demand, and self-service. We're already witnessing this with the rise of Software-as-a-Service (SaaS), cloud computing, enterprise mashups, collaborative intranets that can be maintained almost entirely by workers (Enterprise 2.0), and the growing use of smaller, more granular microapplications such as widgets, gadgets, and visual feeds to combine and connect things together across corporate networks. Applications these days are also more open and federation-friendly, frequently offering Web services and APIs with a high degree of customizable features that make them easier to tailor for specific situations. While there is still a long way to go before we have fully mashable enterprises, today's newest IT solutions are already simpler and sleeker yet more powerful and open than ever before, providing more on-the-ground control, adaptability, integration-readiness, and customizabiity. This is the often worker-driven canvas upon which next generation enterprise architecture must function and thrive.
  • Business units and their workers will become more architecturally-aware and assume more local responsibility for EA. Enterprise architects had to learn the business, now it's the business' turn. The whole story here is about strategic advantage through the application of technology and everyone needs to get on board. Workers need literacy in basic EA principles and knowledge of what their enterprise tools are capable of (as well as when they should get help.) With enabling guidance from professional, full-time enterprise architects (probably still from IT or the CTO/CIO's office) the deeper technical issues can be addressed and the classical traps avoided. In this model, enterprise architects realize they can no longer do it all the themselves, must enable local efforts with the tools and ideas to succeed, and formally deputize deeper down into their organizations while still providing moral support and central guidance, though only when it's essential. How far should they go in doing this? That remains an open question but it's probably surprisingly far down into the modern organization. The key point: Business architecture today is enterprise architecture.

    Am I advocating making everyone an EA expert? Not necessarily, I'm advocating spreading EA responsibility much farther across the organization into capable hands and enabling far more foot soldiers who have a stake and real determinism in what they do.

    Intriguing sidenote: I recently had the privilege of having a conversation with Paul Preiss, the founder of the world's largest formal body of software architects, the International Association of Software Architects (IASA) and he told me that they have learned through many years of instructional development that they can teach almost anyone to be an effective enterprise architect, even if they are non-technical.
  • Competition across the enterprise. While duplicate software and data was previously considered wasteful, it's still surprisingly common in most organizations. The number of duplicate and unnecessary customer databases alone that most businesses maintain even today stands testimony to both the challenges of overcoming Conway's Law as well as a nod to the powerful tribal and organizational boundaries that exist in all organizations. However, overlap in emerging IT solutions on the edge of our organizations for a time actually isn't a bad thing. We just don't have good enough competitive mechanisms for IT solutions inside most organizations; the best perceived solutions to business problems are usually picked up front and then rarely changed, with only occasional drivers for dramatic improvement as systems become outmoded.

    The implication here is that new distributed solutions can crop up, and if successful can rise and become a better and more useful solution. Or they will die away as their faults and failures are understood and a new crop of solutions emerge. The role of traditional enterprise architects here will be to help manage such competition so that it's least disruptive and help manage change.
  • Traditional enterprise architects become mentors to the business units. As business units assume more, though again, not all, control of the architecture of their business (and some of the technology underlying it), they will need serious help. Often lots of it, especially at first. While mentoring is often 2nd nature to architects, who frequently have to work through the hands of others, the increasing distribution of architectural responsibility is going to require considerable bridge building, education, hand-holding, advice, and problem solving. The best part, done right and with a EA help desk (perhaps with an internal community development effort), the phones will ring in IT once again.
  • Better business outcomes. Because more architectural capacity lies across the organization and can help itself within a larger number of situations, better results often occur. This means quicker response to business situations, faster and better application of technology to business problems, and less rework.
  • Now the bad news: Making sure chaos doesn't ensue. The proliferation of new self-service technologies and increasing use of outsourced IT solutions is already giving IT a headache by giving it more to manage, integrate, and connect with. Portfolio management of highly decentralized enterprise architecture is going to require new tools and techniques, though these were needed anyway. Is a 10x increase in maintenance and management effort going to be required? It's hard to say but it's likely. This is where centralized enterprise architects can do enormous service to the organization by getting out ahead and working out ways to enable choice by working with local groups to create common technology platforms and some simple ground rules to keep the new EA manageable. Again, the concept here is think globally, act locally.

I should be clear that some organizations, and probably ones that are having unusual success with their enterprise architectural efforts, are likely doing some of this to some degree or another already. What this discussion is about is what can organizations do today if they want to improve their enterprise architectures in a practical ways using new perspectives, many of which are taken from the hard-won lessons learned of recent years.

Finally, of course, one of the big problems with this whole discussion is that it smacks of architectural astronautics. However, this is the very heart of the problem itself; a lack of close connection to ground reality with only an impartial, external stakeholder's view into the business. Looking at the pitfalls list circulating this week it's clear that opening up and increasing ownership and responsibility of enterprise architecture (something that's going to require a big step up for many managers in most businesses) can address many of the problems being discussed right now. In fact, I'd wager it's one of the few things likely to work.

Given the trend for business units to try to solve more and more IT problems themselves, all of this is not just theory, it's rapidly becoming practice and traditional EA is at risk on many fronts as a result. This means as businesses increasingly mind meld with their technologies and begin to attain truly integrated strategic control over their destiny, the 20th century view of IT and business will almost certainly undergo a transformation like no other it's encountered before.

Where do you see enterprise architecture going? Is EA about to undergo a major transformation or are the current challenges just temporary?


I don't want to sound arrogant, but this "new" approach to EA has been my approach for the last 7 years and is a driving force behind PeaF.

"Enterprise architects are often looked at these days as the police". True, it is part of the job not pleasant, not easy, even resented. I've even seen Enterprise Architect jobs advertised for solely "running the Architecture Governance Board". How can one do that without an EA blueprint, principles, standards work... to check against? This is design by committee in by-weekly meetings.

"Make enterprise architecture far more autonomous, distributed, and loosely coupled". Agreed, but for that, one needs an EA framework so that every piece of architecture, coming from its business owners, fits back in the EA, as the framework dictates.
But every current EA framework is less so since it addresses an aspect or aspects of EA rather than the whole. TOGAF is basically a process, Zachman an approach philosophy and a taxonomy, FEA a layered design, SCOR, NGOSS... are business maps and DODAF is more of a system design method and metamodel. In practice we have to deal with all these EA aspects, rather than only the process, or method, or taxonomy. We need a comprehensive framework, concisely described in a few pages for proper usage.
The EA, as it is, is going nowhere.

Firstly, it needs a full EA framework.

Secondly, the business architecture is a must. How can align the IT to business without a business blueprint? The problem is that neither the business academia nor reputed consultancies have supplied one as yet. I would have said they should have a stake in it. Of course, Porter, since long, talked about Value Chains, which constitute a top level business architecture.

Thirdly, EA must be delivered by a collaboration between business and IT, which was said before. In practical terms, integrate the people organization design work and team to align responsibilities to processes and technology. Also co-opt the Six Sigma business process effort, for instance, in your EA program since it would provide the process documentation and improvement part to your business EA. That will help break, as well, the barrier between business and IT and will rally stakeholders' interest.

Fourthly, the EA architect role must have authority and sponsorship from top management, unlike the current role.


I mostly agree with Adrian Grigoriu. The only comment here is that Value Chain is the old days practice. In current market conditions (and for last 8-10 years) the progressive business model is Value Networks, which is more about 'services' than about 'processes'.

Actually, I have more comments. Decentralisation of the EA is a two-edged sward indeed. All distributed EA must share the same conceptual view on the things otherwise there will be a new tasks of placing them ‘on leash’ first and then allow them to propagate the enterprise architecture to others.

Yes, architectural governance is a very big thing if we want to have EA done right. I disagree that ‘architecting on meetings’, Web 2.0 or in the ‘sessions of House of Commons’ is effective and productive. In each particular case, the minimum of mandatory constraints is different and “security, legal requirements, and the most critical business needs? may be not enough. Here are two very simple examples:
1) assume we have loosely coupled EAs with only constraints listed above. Two local divisions, e.g. in the UK and Australia, perform modifications of the same product fro local needs. The Australia team has updated product documentation in accordance with the enterprise policy while the UK team did not since it is not a mandatory requirements. Does it make any good for the enterprise architecture? I do not think so.
2) Assume a company implements service-oriented model, from the business to the IT, top-down. This is supposed to be the strategic direction but a local business resists because it traditionally does not care about tomorrow and requires making a product patch (which is quicker and cheaper in development than doing in SO manner). If there is no centralised EA authority to stop such business activity in spite of any “local situations?, the enterprise suffer for the sake of local benefits. This is one of the most typical situation in business.

I know that only several industries can benefit from community mind (like entertainment) and it would not be wise to extend the meanings of Web 2.0 on finance, chemistry, healthcare and similar spheres there self-services are rather dangerous if not life threatening. So, this ‘Next-Generation’ EA aspect must be taken with maximum accuracy.

The architecture awareness of business unites will not come from EA until it is under IT roof. The EA has to comprise both Enterprise Business and Technology Architects under cross-functional management to make this ‘awareness’ happen.

“Competition across the enterprise? is common because of EA weakness. Actually, competition is a healthy thing if it is done under strict control. This competition should not come from ‘freedom’ of doing what the local business wants but from the best contribution into the enterprise needs. One of SOA aspect is that any business unit should be allowed to construct any business service (related or not to its LOB); if this service appears better than its alternatives, the unit has to be highly compensated (in the form similar to royalty); if the competition is lost, the development goes for the unit’s charge, like in the market.

I would be afraid if “Traditional [technical] enterprise architects become mentors to the business units?. This is the job for not-widely-existing-yet Business Architects. The result of Business Architect absence is “the trend for business units to try to solve more and more IT problems themselves, all of this is not just theory, it's rapidly becoming practice and traditional EA is at risk on many fronts as a result.?

So, my advice is to re-format EA and make it inter-business-IT organisational entity with appropriate authority influencing both business and IT projects.

Michael, see here http://www.bptrends.com/publicationfiles/04-08-ART-THREE-TheVirtualizationoftheEnterprise-Grigoriu-JE-V._2_.doc.pdf how Virtual Networks fit in the context of the virtualization of the Enterprise.

Adrian Grigoriu

have a look yiwu ,maybe you will search for another, try yiwu china ,Ok.

but I want to tell you there is a execting website dollar stores ,everything just be sold a dollar.yes ,it is true,my friend

Dion Hinchcliffe

Dion Hinchcliffe is an internationally recognized business strategist and enterprise architect View more

Recently Commented On

Joe McKendrick: Part II of II: Designing Evolve-ability into SOA and IT Systems

In part two of Joe McKendrick's recent podcast with Miko Matsumura, chief strategist for Software AG, they talk about how SOA and IT systems need to change and grow and adapt with the organization around it.

Listen Now

Phil Wainewright: Helping Brands Engage with Social Media

Phil Wainewright interviews David Vap, VP of products at RightNow Technologies, and finds out how sharing best practices can help businesses understand how best to engage with online communities.

Listen Now

Peter Schooff: Making Every IT Dollar Result in a Desired Business Outcome: Scott Hebner of IBM Rati

Scott Hebner, Vice President of Marketing and Strategy for IBM Rational, discusses a topic on the top of every company's mind today: getting the most from IT investments.

Listen Now

Jessica Ann Mola: Where Will BI Fit In? Lyndsay Wise Explains

In BI, this tough economy and the increasing role of Web 2.0 and MDM are certainly topics on people's minds today. WiseAnalytics' Lyndsay Wise addresses each of them in this informative podcast.

Listen Now

Dennis Byron: Talking with...Deepak Singh of BPM Provider Adeptia

Deepak Singh, President and CTO of Adeptia, joins ebizQ's Dennis Byron in a podcast that gets its hand around the trend of industry-specific BPM.

Listen Now
More Podcasts

View All Webinars

!-- SLOT SkyBanner -->