It is interesting to watch the debates online between the different schools of thought of Enterprise Architecture. The discussion was started by James Lapalme, who published a paper on “three schools of thought” which is in pre-print for the IEEE’s IT Professional journal. (citation) Mostly the online discussion focused around the role of the newest domain of Enterprise Architecture… the domain of Business Architecture. Depending on how Business Architecture is understood, the role of EA can be dramatically different.
- Some say that EA is about improving IT. In the diagram below, this is “Enterprise IT Architecting.” In the online groups, we call this EITA. In this model, EA is a mechanism for designing IT services and creating IT systems that address enterprise needs. It’s just a bare step above Enterprise Application Architecture by operating outside the constraints of funded projects, but the impact occurs in IT. For this first group, Business Architecture is just another name for Business Analysis.
- Others say EA is about aligning the business with all of its capabilities, including IT. For these folks, Business Architecture exists, but it’s primary impact is internal. Business Architects insure that the right initiatives are created in order to achieve business strategy. In the diagram below, this is labeled “Enterprise Integrating.” In this school of thought, Business Architecture doesn’t really impact business strategy. Business Architecture uses capability analysis to understand the impacts of strategy on the business processes and systems, and helps to frame the initiatives that should be created. Only after the initiatives are started would a business analyst even get involved. In this model, EA provides all the benefits of the first group, AND insures that investments are made in the right place.
- A third group say that EA is about Enterprise Ecological Adaptation. For these folks, Business Architects help analyze the movements of the market, and work closely with business leaders to develop strategies based on the capabilities and positioning of the company that are likely to generate new revenue, improve market position, improve customer loyalty, and reduce costs. EA and Business Architecture help the business adapt to the ecosystem in which it exists. In this model, EA provides all the benefits of the first two groups, AND insures that the business responds to the market conditions in a logical manner. For some in this camp, Business Architects are not even part of EA.
Depending on the company your work in, there’s a case to be made for each. Personally, I prefer to think of EA as alignment at the minimum, and strategic effectiveness as an ideal state. I created the following image to illustrate these distinctions. For further reference, please read James Lapalme’s paper in the IEEE IT Professional journal.
18 thoughts on “Three Schools of Thought for Enterprise Architecture”
Great summary, Nick!
Interestingly, exactly the same not-quite-layering also applies to other views into the organisation: BPM (business process management), for example, or ITSM (IT service-management in general). In effect, they all start to meet up at the 'Enterprise Integrating' layer (as TOGAF sort-of acknowledges in its view of Business Architecture), and must interweave at the Enterprise Ecological Adaptation layer (otherwise it ain't a broad enough view of the enterprise-ecology).
I see those three areas not so much as layers or intersecting sets but as selected subsets of or views into the same (vast) scope, with the key boundary-criteria being themes such as skillsets and methods. In terms of your vertical axis, 'lower' is more specialist, domain-specific and concrete; 'upper' is more generalist, cross-connecting and perhaps seems a bit abstract – though I'd agree strongly with you that 'Enterprise Ecological Adaptation' is also very much about the immediate and concrete ('projects') in a kind of 'think global, act local' sense.
We could also redescribe those 'schools' in terms of their view or focus:
– 'Inside-In (domain-centric)': Enterprise IT Architecting (and equivalents such as BPM)
– 'Inside-Out' (organisation-centric): Enterprise Integrating
– 'Outside-In' (holographic, no 'centre'): Enterprise Ecological Adaptation
Hope this makes sense?
I've seen companies with gaps where EA does not exist as well as overlaps with BA and existing capabilities in IT when EA is introduced. It would be nice if you can share your own thoughts on the domain where EA can fit effectively. Would it actually make more sense to have reasonable overlaps, or it is the time to re-balance the borderline between EA, BA and IT.
As an EA practitioner since early days (circa 1997 – e.g. Using Reference Model for Open Distributed Processing, now included in TOGAF9), I believe it is important to get simple things right:
Let us do a bit of RACI analysis to put EA into perspective:
1. Enterprise architects do not own business strategy. That is owned by CEO and CxOs (business unit heads). EA are "I"nformed, they may be "C"onsulted on specific business-centric issues e.g. social networking as a channel, improving marketing and advertising through big data insights.
2. EA's realisation of business strategy into an operating model constitutes a business architecture. Senior business managers and executives are "A"ccountable and even "R"esponsible for overall, holistic "business architecture", or "process flow" and overall information management. This covers non-automated and automated (yes, IT is still automation) aspects. Again, EA role here is "C"onsulted, "R"esponsible for developing full EA for the automated components.
Enterprise IT Architecting is largely non-controversial. Enterprise Integrating is what I have summarised in the 2nd point above.
Enterprise Ecological Adoption is the tempting career path that many EA and even CIO attempt to take, trying to transition from IT domain to the business domain. I can think of many CIOs, and not so many EAs, who having been capable of contributing this value, have hit career brick walls.
Reality is that business accountabilities are different from IT accountabilities, regardless of how strategic IT becomes. With the right executive and organisation support, the transition is possible.
Rest of this discussion is architects trying to impress other architects, and finding their place in the architecture pecking order.
CIOs and EA attempting to foray into Enterprise Ecological Adoption, other than as trusted advisors, may find their CIO (career is over).
In our case, I believe EA is implemented on the basis of an organizations existing structure. Depending current goals and achievement EA can be changed and modelled to Company's advantage.
There is forth school of thought which most EA practitioners conveniently leave behind is about delivering value to organization by exploiting ICT capabilities. EA is no different what Industrial Engineering has been for more than 100 years.
EA is focused on influencing Enterprise Capabilities through ICT Capabilities where as Industrial Engineering focused on improving supply chain performance by focusing on people, process and technologies in industrial economy. Given that our economies are now about services, not industrial .. EA can be seen as Service engineering. Principles, roles, responsibilities and skills are all the same.
Unfortunate thing is most EA’s lack basic industrial engineering skills and hence they don’t even think it is their job. Reason why EA has not gained any significant foothold in corporate culture.
You are correct in this statement: Business accountabilities are different from IT accountabilities. That is why the EA's that are successful in Enterprise Ecological Adaptation do not work for IT. This debate has been going on for a long time. EA's see the limitations in working for IT, and many are transferring to positions that are outside of IT and in various business planning and strategic advisor roles.
You clearly fall into the "Enterprise Integrating" school of thought. That said, your opinions and experiences, valuable as they are, do not make the other schools of thought "right" or "wrong." Others believe differently from you. I've met them. They claim success. Each in their own sphere, in their own school of thought.
Let's give credit where credit is due. Jame Lapalme came up with the notion of three schools of thought and I've read his paper that is due for publication by the IEEE. This is not the first place where the idea was surfaced. James himself discussed the idea, and shared the paper, on LinkedIn many months ago. I created the graphic and wrote a short blog to explain the idea. James gets the credit for doing the hard work.
My simple article does NOT attempt to declare one "school" to be better, or more accurate, or more attainable, than another. Your response clearly indicates that you believe that someone attempting to be part of the third school will find themselves "CIO (career is over)." Your disdain couldn't be more obvious. However, I am not attempting to take a position on any of the three. I'm simply pointing out that there exist three camps.
The reason for pointing out this fact is that we have to communicate amongst ourselves. In order to do so, it is helpful to understand the motivations of both the speaker and the listener. If each of us become aware of the three schools, we can quickly place OURSELVES in a school. We can identify ourselves when we meet another EA and thus help to create that common understanding.
We all know where you sit. That's great. It's a start.
The schools of thought are about us, the EA community, not the businesses we work for. Clearly, if there is a mismatch between what an EA wants to deliver, and what they are allowed and expected to deliver, there can be some unhappiness. The best EAs will be properly placed, but good fortune comes to the prepared. Be ready for any situation, and perform well wherever you land.
Your variation in the monikers makes perfect sense. I don't have a "perfect" terminology, so yours is as good as mine.
The fact that you view each of these as subsets shows that you are prepared to behave in any of the roles demanded of you as an EA. That demonstrates your maturity as an EA, and an aspiration that all EAs should seek.
about the "boundary line" between EA, BA, and IT… that would be a good topic for another blog post :-).
Nice blog, clear picture!
you mentioned the original paper was discussed on LinkedIn a few months ago, do you have a link to that discussion?
Certainly a good start; EA overall complexity is a bit wider and deeper, this is clearly a modular overall view. Parts that are not addressed in this view would be additionally the ability to maintain an understanding of how business solutions function while mirror business directions throughout the business life-cycle while ensuring business agility through adjustments. I would enjoy aiding in continued development if/as interested. Thinking about adding more broadly steps with business needs based on a myriad of controls/constraints such as but not limited too political federal/local, social, economic and religion interests.
Fascinating response. I'd love to see what the addition of those attributes would do to the simple conceptualization described here. It's possible that you add an entirely new dimension to the view, which may require a different visualization (or a set of visualizations) to illustrate properly. Feel free to contact me directly if you'd like to collaborate.
I am curious: when you say that I did not address "an ability to maintain an understanding of how business solutions function", are you saying that you want to model the ability of a company to maintain their own Enterprise Architecture practice?
If that is the case, I'd suggest that you stay tuned. I will be sharing the "dual maturity matrix" that my team uses to illustrate the value proposition of an enterprise architect, working in a business segment. I developed the model with the input from my team as a way of helping the architects position themselves and their outcomes in a measurable manner. That mechanism does capture the "ability to maintain an understanding" (in the form of an architecture) "of how business solutions function."
Thank you for your unique insight
> are you saying that you want to model the ability of a company to maintain their own Enterprise Architecture practice
EA is a part of the enterprise just like any other part – it is the part of the business that builds models to understand the dynamics of the 'ecological environment' – and guide actions to adapt, survive and prosper.
Of course EA should model itself – it is a part of the adaptation system. Given the remit to describe the _whole_ enterprise – on what logical grounds would EA not model itself? Surely such a view would be self-contradictory?
Ian, your logic makes some sense… If the EA function is so mature that it makes sense to consume precious resources to model EA instead of an area of the business that is part of the value chain. Sure, you could model EA… But if you follow the rules of alignment, few professional EA teams would. Use of Simple maturity models will do the job. Let's apply the rules of alignment to our own efforts.
Looks good, Nick.
Let's not forget there are different customers for each of these and hence different value propositions. Be interested to see some more detailed thinking about the real value add of EA when other disciplines also have value to contribute.
Thanks for responding. It is true that each has a value proposition and a different role to play. Each is a description of a stable, valuable, effective role. I figure that's why we see folks cling to the one that they are the most familiar with. Each are "right" yet all are wrong (reference to the Three Blind Men and the Elephant poem).
I agree that other disciplines have value to add. You'd have to pick one of these three and detail out the points of interaction in order to discuss the value proposition of that school. Unfortunately, the other disciplines are not consistently used either. In a sense, you'd have a different value propositon for each role in each organization or enterprise.
That's a lot for one person to detail out! I wonder if that diversity of implementation provides us with the diversity of opinion about the "right" way to perform EA.
After, if Joe is comfortable working in the "Enterprise IT Architecting" space, and works well with business analysts who call themselves "business architects," how will he describe his value proposition to Mary who also works in the Enterprise IT Architecting" space, but whose company doesn't hire business analysts, and expects IT "Deliver Managers" to perform those responsibilities? The value of the EITA, in those cases, would differ.
That same conundrum presents itself for literally hundreds of combinations of EA (in a school of thought), and groupings of collaborating roles that specifically exist in a particular corporate culture.
If you know the magic combination, please share it. Just be aware, the combination that is "magic" in one company may be wildly ineffective in another.
Thanks for making me aware of this Nick, – and of the writing of James Lapalme! Having met ‘representatives’ from each school I find it so well captured. While large analyst companies like Gartner speak about the the two perspectives depicted lowest in the illustration (i.e. Enterprise IT and -Integration), the third (Ecological) seems like a more recent – and refreshing – awareness. Good work!
Nice article. My natural tendencies has me reading the image as though it is demonstrating a type of maturity model. Companies continue to make profits wherever they are on an SDLC maturity model and as such there is no "one best" School of Thought," only alternatives to try.
Another point your illustration reminds me is that our communication is only as good as our tools. I am sometimes frustrated trying to relate a 3D (or 4 or 5D) concept within a plane. As Buzz Lightyear might say "To infinity and beyond."