I recently heard that others in my organization are attending TOGAF (The Open Group Architectural Framework) training. I have been trained and certified in TOGAF for about 4 years now, but within SIS and later within Atos I found very little interest in the subject, despite TOGAF being arguably the defacto standard in architectural frameworks. This is primarily due to the fact that Siemens has Chestra and Atos Origin had CLEAR as their Enterprise Architecture frameworks. On top of that, we in GST do not do Enterprise Architecture, instead we are focused primarily on Solution Architecture and then only within the Technology Architecture domain. I think however, that an understanding of an Enterprise Architecture framework would be beneficial for all GST Solution Architects because it will put a lot of what we are doing into perspective and provide better understanding of the customer’s motivations and objectives.
TOGAF is used by organizations to develop and maintain their Enterprise Architecture and divides Enterprise Architecture into 3 primary domains:
As I mentioned above, GST Solution Architects are primarily focused on developing the Technology Architecture. This, however, is dependant on the customer’s Information System Architecture, which in turn is dependant on the customer’s Business Architecture. It follows then, that in developing our solutions, we are providing only a portion of the customer’s overall Enterprise Architecture (EA), and then only as part of an overall EA methodology. This is best seen when one looks at the TOGAF Architecture Development Methodology (ADM) shown in the following diagram:
By the time the project lands at Atos’ door, the customer has, whether using TOGAF, another framework or other informal processes, already developed their Vision, Business Architecture, and Information Systems Architecture (A, B and C above). This information would be placed in an RFP and forms the basis for the information we would use to develop our Technology Architecture (D). So when reading and assessing RFPs, it is important to pull these pieces of information out of the RFP and document them as part of the overall Solution Strategy. The gaps between the Technology Architecture we develop and the current customer Technology Architecture (CMO) make up the Opportunities and Solutions. These become the transformation projects which must be implemented. The migration planning is then the T&T plan we develop (F). Of course our Technical Architecture has implications for the Business an Information Systems Architectures, so the customer, in their evaluation must assess the impact to the Information Systems Architecture and maybe even the Business Architecture. It is for this reason I think it is very important for Solution Architects to understand how our solutions fit into an overall EA methodology and how they relate to other architectural domains. For me, TOGAF seems to be the logical choice for doing this.
