For the longest time since I began this course and journey for an Enterprise Architecture certification and degree, not one person in my field has really understood EA. The initial thought always surrounds the actual title of Enterprise Architect and gets categorized with “someone who oversees our IT infrastructure and Networks”, and that’s where it stops! Enterprise Architecture as a strategy and as a verb is new to many. Little does everyone know, EA is the work being done EVERY DAY.
I work for a travel technology company, and we constantly review the current state of our organization and many times have tried to assess the future state of our business strategy. Without knowing, we have documented and created artifacts based on our EA structure and have created roadmaps based on business information and our technology. According to the Gartner article by Lapkin, A. (2006). Activity Cycle Overview: Enterprise Architect, 5, identifying current and future EA state, addressing gaps through analysis, defining roadmaps, and creating guidelines for technology processes to achieve future states, are all a part of enterprise architecture. This is the idea I would love my organization and other partners to understand.
It’s difficult to see where an organization is taking their EA strategy when the enterprise architects are not included in everyday product discussions. As a product manager, our goals and initiatives should always involve input from enterprise architects. Architects understand the life-cycle and risks associated with aspects of various frameworks. In another Gartner article by Allega, P. (2006). Enterprise Architecture: Just Enough, Just in Time, 3, there is a diagram I can truly appreciate.
I recently completed a Pragmatic Marketing certification class, and kept thinking about the above diagram, and why, why was this the framework selected for our entire organization? So many choices, so many ideas, as I questioned our trainer about different EA processes I never really received a satisfying response. While the above diagram does not represent a framework, it represents a process. An overall EA process that explains exactly where our organization stands and what type of state we all want to achieve. The model above represents a top-down initiative that involves a business strategy surrounding communication, values, culture, acceptance, and standards. Without the successful implementation of processes, any EA framework will have a shaky foundation.
My organization is especially advanced in creating artifacts and identifying and articulating our strategy and principles. Artifacts are documents that should be accessible by anyone in the organization. Have you heard of SharePoint? Yes, we are big fans. Any document for any team or team member, you will find it on SharePoint. I have to admit, SharePoint is not the most intuitive nor the prettiest, but it gets the job done. From engaging leadership in strategy talks to documenting new processes, artifacts should be widely understood. I have focused on creating documents that are “readable” by different roles in the organization, so each person understands the purpose and vision.
Overall, enterprise architecture based on the conversations I’ve had is widely misunderstood. I’d like to reference the EA3 Cube as a common framework for technology companies.
(Bernard, 2012)
Without mine or your organization knowing it, they probably already have artifacts depicting each level of the cube. The trick is learning, engaging, and maintaining the vision and process of the organization.
Enterprise architecture is business + strategy + technology and how these all come together to make an organization efficient and effective. I believe all organizations should have solution and enterprise architects. They are the foundation and enterprise architecture is their manual. Working for companies in the hospitality industry for most of my career, I have realized the importance of enterprise-wide initiatives and being able to change and adapt to the market.
If you enjoyed this reading leave a comment below!
References:
Allega, P. (2006). Enterprise Architecture: Just Enough, Just in Time, 3
Bernard, S.A. (2012). An Introduction to Enterprise Architecture (Third ed.). Bloomington, IN: AuthorHouse.
Lapkin, A. (2006). Activity Cycle Overview: Enterprise Architect, 5
The Strategy of Enterprise Architecture 
Truly well put. I can’t tell you how many discussions that I have had with people that just don’t quite understand the totality of Enterprise Architecture. To be honest, it doesn’t surprise me though since prior to last summer, I had never even heard the term before. But since then, however, I have engaged numerous people in conversations, only to realize that it is a very mysterious field to those that are not familiar with it. I completely agree with you that most companies probably have many of the pieces and artifacts necessary to establish a mature EA framework, still they do not possess the skills nor the foresight to put it all together.
LikeLike
You mention that Enterprise Architects are not included in every day product discussions, and we run into the same thing in mine. I think it goes back to your first point, where folks more often think of Enterprise Architects in relation to Technology Infrastructure, rather than as business contributors. It seems this would be an addition to the argument of where the EA should physically report to in the Organization.
Also – I totally agree about Sharepoint. It does the job, just not real intuitive. We are slowly changing over to Confluence, which although a bit of a pain, I think has more opportunity for a robust repository.
LikeLike
Confluence? Maybe i can suggest that to our time! HA.
LikeLike