By Terry Blevins, Fellow of The Open Group, Enterprise Architect at Enterprise Wise LLC
It is a little funny. I hear a lot of divergent thoughts about specific elements of TOGAF®, an Open Group standard. One time I was talking with someone in a conference and the conversation went to the subject of those elements of the TOGAF standard that were undervalued and needed further exploitation. In another conversation, I was talking with someone else who was concerned with elements of the TOGAF standard that weren’t valuable and should be removed. The funny thing was that in those two conversations the same thing was brought mentioned … the Enterprise Continuum.
Having many conversations specifically about the Enterprise Continuum, I realize that the concept is not easy to grasp. I also viewed some internet discussions on the topic of the Enterprise Continuum that reinforced this concern. So I thought a blog might help.
First a little background. The first 6 versions of the TOGAF standard were documented yearly in paper form from 1995 to 2000. In 2001, the first web version was published on the internet as TOGAF 7. This was followed by TOGAF 8 in 2002, TOGAF 8.1 around 2003, TOGAF 9 in 2009, and TOGAF 9.1 in 2011.
Each version of the TOGAF standard was intended to add to the value of the framework based upon best practices used by active architects. These best practices would be selected for use in a given architecture endeavor as appropriate. The TOGAF framework was never intended to be a recipe or step by step prescription.
In the early years 1994 through 2002, there were a relatively small number of contributors since the community was smaller. In subsequent years, the number of those involved in its evolution grew. This resulted in a change to the release cadence from a yearly publication to a more open ended release cycle.
THE TOGAF TIMELINE
1994: Requirement Proof of need
1995: TOGAF Version 1 Proof of concept
1996: TOGAF Version 2 Proof of application
1997: TOGAF Version 3 Relevance to practical architectures (building blocks)
1998: TOGAF Version 4 Enterprise Continuum (TOGAF in context)
1999: TOGAF Version 5 Business Scenarios (architecture requirements)
2000: TOGAF Version 6 Architecture views – IEEE 1471
2001: TOGAF Version 7 Architecture Principles; Compliance Reviews
2002: TOGAF Version 8 Extension for Enterprise Architecture
2009: TOGAF Version 9 Architecture Content Framework and Architecture Capability Model
I have gotten off track, but hopefully some of the background was useful. So back to the subject of the Enterprise Continuum.
CAVEAT EMPTOR: When I discuss the Enterprise Continuum, I am referring to the original Enterprise Continuum as documented first in TOGAF Version 4 back in 1998. Wow – we were discussing this 19 years ago! The Enterprise Continuum has evolved since then, most radically in TOGAF 9. Regardless understanding the original intent may be enlightening and help you understand why you should think about it today.
So to start out, let me recount some of the discussions we were having when developing the TOGAF framework in the 1997-98 timeframe. Key for the reader is to ask – are these subjects still relevant today?
We were really thinking hard about whether TOGAF should stay in the Information Technology (IT) space versus the “enterprise” space. Most of us thinking we need to go beyond IT architecture. When we agreed to proceed in the enterprise direction many things emerged as important including thinking about services – not just IT services, but business oriented services. We thought a lot about building blocks. As a matter of fact, if you got a hold of an old version of TOGAF, you would see interesting treatment of building blocks and services, and how they would be used in the Architecture Development Method (ADM). Of course the subject of building blocks generated a need to distinguish between architecture building blocks and solutions building blocks, and their relationship. Additional discussion uncovered the observation that there were common problems across enterprises addressed by different architectures and solutions. Another interesting discussion was around the concept of reuse, at that time reuse was a huge subject. When we thought of enabling reuse we figured it could and should start with architectures, especially if you could see what solutions complied with specific architectures. There were many other things going through our minds, like “webifying” TOGAF, but each of the above thoughts and discussions lead to the need for something … that something becoming the Enterprise Continuum.
So at that time the following observations were implicitly driving our work:
- Not one architecture that can cover any complex enterprise!
- An enterprise has multiple architectures, each bounded in scope
- It is not just about IT!
- An enterprise approach must deal with people, process, and technology
- Reuse is good!
- Leverage architecture building blocks
- Architecture aren’t solutions!
- But solutions should at least be guided by architectures, on other side comply
- There is a great deal of unrecognized commonality!
- So collect architectures of common scenarios
- More specialization is needed closer to the business and/or mission!
- There is a continuum of very general scenarios to very specific scenarios
- Good to know what solutions comply with what architectures!
- If you find an architecture that you can use, it is better if you know what solutions implement the architecture
With these observations came a challenge to depict how one might classify and manage information about architecture and solution building blocks. Having such a construct then enabled organizations to save a lot of time and money, and enabled them to apply limited resources were specialization will bring the greatest return! Seriously – we were thinking about this in 1997. Why architect if you can find an architecture to reuse? It wasn’t just us, there were others working on architecture patterns.
Hence the “Enterprise Continuum” which denotes the combination of two complementary concepts: the “Architecture Continuum” and the “Solutions Continuum”.
- The Architecture Continuum represents a structuring of re-usable architecture assets. The Architecture Continuum is directly supported by the Solutions Continuum. The Architecture Continuum is a useful tool to discover commonality and eliminate unnecessary work.
- The Solutions Continuum provides a consistent way to describe and understand what solutions implement elements of the Architecture Continuum. The Solutions Continuum defines what is available as re-usable building blocks.
Fast forward to today – the IT4IT™ Reference Architecture is a perfect example of an architecture that would be described as a part of the architecture continuum. Right now many organizations around the world are reusing this reference architecture, either in whole or through adaptation. Additional reference architectures are emerging such a Health Enterprise Reference Architecture (HERA)! Many more to come!!!
Summary
The big question you need to ask yourself – whether you are an Enterprise Architect in an organization, or an Enterprise Architect Consultant – will reusing architectures and solutions help achieve success? If so then you should think about creating your own Enterprise Continuum or support the creation of an open Enterprise Continuum for all to benefit.
One person I encountered expressed a view that the Enterprise Continuum is an anachronism … they may be right, but not in the sense they believe. The Enterprise Continuum may have been out of place in the past, but just maybe it is the right time now.
@theopengroup
Terence Blevins, a Fellow of The Open Group, is owner of Enterprise Wise LLC and a semi-retired Enterprise Architect. He is currently a Director of The Open Group Governing Board and an active contributor to the Healthcare Forum within The Open Group.
Terry has been involved with the architecture discipline since the 1980s, much of which was done while he was Director of Strategic Architecture at NCR Corporation. Terence has been involved with The Open Group since 1996 when he first was introduced to The Open Group Architecture Forum. He was co-chair of the Architecture Forum and frequent contributor of content to the TOGAF® framework including the Business Scenario Method. Currently he is excited to help the Healthcare Forum work on Boundaryless Healthcare Information Flow.
Terry was Vice President and CIO of The Open Group where he contributed to The Open Group vision of Boundaryless Information Flow™.
He holds undergraduate and Masters degrees in Mathematics from Youngstown State University. He is TOGAF 8 certified.