English | EN 
Before I jump into the deep end of my experience with Enterprise Architecture, I first wanted to touch on our Capgemini Integrated Architecture Framework (IAF). It is our (Capgemini’s) architecture framework that has been developed over many years dating back to 1993 with the publication of the initial draft. It has been described as the “piece de resistance” by our Global I&D CTO of Insights and Data, Ron Tolido [1]. And continues to be developed, acting as the innovation hub for new architectural thinking, application, and techniques [1]. I have not obtained my Capgemini certifications in either role based or architecture frameworks but am on the path to obtain both. And am looking forward to contributing to the ongoing evolution of IAF.
On to my experience with Enterprise Architecture. Like so many other things in life our current point of view have been influenced by our experiences. What I believe today, as it relates to Enterprise Architecture, is very different than where I started over 20 years ago. Many organizations I have been a part of, focused on developing their Enterprise Architecture practice within the function of Information Technology (IT). To better understand their infrastructure and application landscape. The stakeholders were typically technology focused. While minor success was realized in alignment of applications to infrastructure, the alignment to the business functions the applications support was not clear. The organization was not able to articulate the value of technology in terms of the business or, effectively manage risk across the enterprise.
As I became a “student” of Enterprise Architecture, I began to think about the most successful organizations in the world, who do you think came to mind? Were they experts in their business? Was their entire organization aligned to a single vision and mission? Were they able to easily articulate the value of technology and manage risk? I know the ones that I thought of were able to do all three.
Enterprise Architecture when properly evolved in an organization starts with the business [2]. An inverted pyramid: where information is spans across business functions that in turn are supported by applications that run on infrastructure. The Enterprise Architecture of an organization must be defined by stakeholders from across both business and technology functions [3]. It must start with a clear and achievable business strategy with (a) defined operating model(s). Simply put (and worth repeating) Enterprise Architecture is a function of the Enterprise. Only then will the organization be able to draw a clear line of site across the entire organization, easily articulate the value of technology in terms of the business or effectively manage risk across the organization.
Through my years of experience, it became clear that the structure used to describe the dimensions of Enterprise Architecture needed to be multi-faceted. More than a few aspects spanning business, information, application, and infrastructure architecture. More than a few abstraction levels spanning contextual, conceptual, logical, and physical. It also had to have perspectives that passed through the others around security, quality, integration, and more [3]. It required overarching guidance that linked it all to the enterprise strategy and performance, and it required a governance mechanism that supported it all to ensure complete and consistent execution. This is where IAF and my point of view are perfectly in sync [1]. The journeys may have been different, but the result is the same.
As we look to apply this, or any other, framework to an organization it is important to remember that no two organizations are the same. They may be similar in many areas, their industry, the types of products and services they offer, their organizing structures, the technology they use; however, they are all unique. I say this because, as we look to apply what we know about Enterprise Architecture we must pause and first understand the unique characteristics and qualities of the individual organization [2]. To do this, there are a few key activities that must be completed.
- Define each dimension of Enterprise Architecture in the context of the unique organization. “Who”, “What”, “Why”, and for what purpose questions must be asked and answered.
- Create (and maintain) an organizational specific definition of each dimension.
- Identify what does the organization “Do” and what do they do that supports it?
- Document and understand how the organization is structured and how it operates.
The process I have defined and followed to complete these activities will be the focus of future blog posts. I will continue to link my personal experiences to Capgemini’s Integrated Architecture Framework (IAF) [1]. I also plan to share details about my certification journey at Capgemini.
Look for these topics in the future:
Digging into my Enterprise Architecture experience – continuing the discussion about my experience with building high-performing Enterprise Architecture practices with a focus on execution
Influence of other frameworks on how I think about EA – How my perspective of Enterprise Architecture has been influenced by other frameworks like Six Sigma, LEAN, CMM, SaFE and others.
Connecting all the dots series – How to define your architecture building blocks that can enable end to end traceability from business objectives all the way through infrastructure.
Extreme EA – Extending ideas to the edge.
The Art of Influence – How to use Enterprise Architecture to get the right job done right.
Works Cited
[1] Capgemini, “Architecture Framework 2022-08,” 2022. [Online].
[2] J. W. Ross, P. Weill and D. C. Robertson, Enterprise Architecture As Strategy: Createing a Foundation for Business Execution, Boston: Harvard Business Review Press, 2006.
[3] M. Godinez, E. Hechler, K. Koenig, S. Lockwood, M. Oberhofer and M. Schroeck, The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight, Boston: Pearson Education, Inc. as IBM Press, 2010.
