In 1987, John Zachman published an article in the IBM Systems Journal called A Framework for Information Systems Architecturewhich laid the formalized foundation of Enterprise Architecture. In the 1990s, John Zachman further develop the idea to classify, organize and understand an organization by creating The Zachman Framework™. The Zachman Framework™ talks about understanding an organization in terms of:
Today, the field of Enterprise Architecture (EA) also draws from the fields of Engineering, Computer Science, Business Administration, Operations Research, Psychology, Sociology, Political Science, Public Administration, and Management. Due to the advancements and inclusion of various fields, the definition of what EA is continues to evolve depending upon if you are a practitioner, academic, vendor or government but the basic premise of Enterprise Architecture is to holistically understand the entire organization to make management decisions.
In addition to The Zachman Framework™, there are many other EA frameworks that have emerged over the years to help an organization understanding where they are (current state or as-is), where they want to be (future state or to-be) and what steps (transitions) they should take to get to the future. Some of these EA frameworks include:
The Open Group Architecture Framework (TOGAF)
Federal Enterprise Architecture Framework (FEAF)
Department of Defense Enterprise Architecture Framework (DoDAF)
To be clear, EA is not only about frameworks but its also about the EA methodology, tools, artifacts, and best practices. As you develop EA within your organization, you will realize that not all frameworks and tools would fit perfectly but it is a continuous improvement over time. Regardless of the size of the organization, EA can help create a holistic thinking mentality, optimize business processes and improve decision-making.
By now you might be thinking that of course, EA is the answer to your woes. But hold on! Before you jump into EA, it is critical to know: 1) The term EA and its jargon can confuse people, 2) EA is about the entire enterprise (aka organization) and not about just certain functions of the organization, 3) People working under the EA function should have a complete grasp of Business operations and IT capabilities, 4) EA is not an IT activity and 5) EA’s purpose is to communicate what is happening and what could happen.
For organizations, EA is like an overarching umbrella which when used effectively can have a profound impact but if used incorrectly can turn into a burden to carry. Keeping these things in mind, let’s ask the following questions:
Who is demanding the need for EA and who is creating it?
Who should be demanding a need for EA and who should be creating it?
What if EA fails?
What should happen when EA fails?
Where EA is helping in decision-making?
Where EA should help in decision-making?
When EA artifacts are being collected?
When should EA artifacts be collected?
Why EA is being used?
Why EA should be used?
As we can see, whoever sees a need for EA matters, EA champions within various organizational functions matters, EA execution matters, EA measurement matters and EA best practices for organizational-wide improvement matters. It should be noted that all organizations do EA in some way (unformalized, semi-formalized or fully formalized).
Success! You're on the list.
Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.
In the video below on CxO Talk, I asked Edna Conway, CISO of Cisco about how architectures fit into each other.
In my view, Security Architecture is a subset of Enterprise Architecture. However, since security is important at all levels, a Security Architecture gets deep into and can work in parallel with Enterprise Architecture. At the user level, perhaps we should know the threats that are out there.
Success! You're on the list.
Whoops! There was an error and we couldn't process your subscription. Please reload the page and try again.
In the video below on CxO Talk, I asked Anthony Joyce, Deputy Chief Information Officer of NAVFAC at The US Navy about the link (or lack of) between a technical framework to the culture of the organization.
In my view, there is direct link between an enterprise architecture framework and an organization’s culture. Enterprise Architecture frameworks requires us to understand where we are, where we want to be and how to get there. We put all of this information on a piece of (big) paper so that everyone has a broad view of what is going on. All this information is gathered by people who talk to people and created for people.
An organization’s culture comes into play when people who are gathering this information are limited to what they can gather due to some pre-established rules and norms of the organization
An organization’s culture comes into play when people who are providing this information are not comfortable with sharing everything since it might be preceived as a danger to thier job security
An organization’s culture comes into play when the people who this information is created for are only interested in confirming thier own biases without thinking holistically
This article proposes the establishment of a Center for Operations, Research, and Education (CORE) at your university. CORE would be a team of people that proactively and holistically help achieve the university’s business outcomes. Its mission would be to provide comprehensive educational programs in Enterprise Architecture, conduct research and use this research to help transform the university.
For this article, the strategic direction and cultural factors in relation to operations, research and education in Enterprise Architecture are considered. We assume the status quo in regards to your university’s culture for this assessment, specifically the perception of Information Technology. The following table shows what we considered:
Current State (Observations)
No one is responsible for Enterprise Architecture
No research is being conducted in this field
No comprehensive program in Enterprise Architecture
Future State (Recommendations)
CORE would be independent of your university’s President
Rotating leadership where every school, department and division has the opportunity to lead CORE
Conduct research by partnering with other elite institutions
Begin by providing a graduate certification program
Aim for providing Bachelor’s, Master’s and executive programs in the future
This assessment reveals that currently where Enterprise Architecture is placed in the organization, it will not be able to provide the organizational transformational value that aspires to provide. Additionally, your university should start providing comprehensive programs in this field otherwise they would be left behind other educational institutions that are already moving in this direction.
This section provides an analysis of standing up CORE from an operational, research and educational perspective.
Your university’s executive management would support this effort
All university communities would help transform it to achieve operational excellence
Perception of IT would not change instantly
1.1 What is the Center of Excellence?
According to Tarek M. Khalil et al. (2001), within an organization, a Center of Excellence may refer to a group of people, a department or a shared facility. It may also be known as a Competency Center or a Capability Center. The term may also refer to a network of institutions collaborating with each other to pursue excellence in a particular area.
1.2 What is Enterprise Architecture?
Due to the evolving nature of this field, there are many academic and practitioner definitions of what is Enterprise Architecture. For our purposes, we will use the one definition from the glossary on Gartner’s website that states Enterprise Architecture as a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. Enterprise Architecture delivers value by presenting business and Information Technology (IT) leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. Enterprise Architecture is used to steer decision-making toward the evolution of future state architecture.
In a nutshell, “Enterprise Architecture bridges the Business and Information Technology via enterprise integration/standardization resulting in people becoming more efficient and effective in achieving their objectives.” Kevin Smith (2010)
It should be noted that Enterprise Architecture is not an Information Technology endeavor but in fact, it sits in between Business and IT and works across organizational silos.
1.3 What is CORE?
If we combine the two definitions above then a definition for the center of excellence in enterprise architecture emerges which is a team of people that proactively and holistically help achieve business outcomes. For your university and breadth of this center’s agenda, it would be called Center for Operations, Research, and Education (CORE).
1.4 What are the Operational Perspectives?
1.4.1 Why should Your University Pay Attention to Enterprise Architecture?
One of the biggest proponents and users of Enterprise Architecture is the most powerful office in the world – The White House. The United States Federal Government has been using Enterprise Architecture for more than a decade and continues to see it as a way to look across organizational silos.
What this means for your university is that huge organizations are trying to improve their operations and they are turning towards Enterprise Architecture to help them do that. Your university can tap into this, apply Enterprise Architecture effectively and perhaps get involved in Enterprise Architecture discussions for organizational improvements. This involvement could also translate into future research grants and job opportunities for students.
1.4.2 Why putting Enterprise Architecture under Information Technology is Not a Good Idea?
All organizations are a composition of many cultures and subcultures. Some of these cultures develop over time and then become part of the routine mentality of an organization. Your university is not immune to this. In order to understand the perception of Information Technology at your university, look at how the university’s strategic plans were developed. Was Information Technology involved/invited to help in the development of your university’s strategic plan?
If not, then this is a cultural issue and often the cause of misalignments within organizations. Whenever Information Technology is not involved in strategic planning, it gives the perception that Information Technology is not important, it is just a commodity and it is just back-office activities. This lack of involvement is the reason that according to the 2013 Chief Information Officer ‘State of the CIO’ survey, “63% [of the respondents] say the majority of their time and focus is spent on aligning Information Technology initiatives with business goals.” This shows there are gaps in aligning Business and Information Technology. This alignment can be achieved through Enterprise Architecture. According to a Gartner study (G00146809), Business-Information Technology alignment is the primary driver for Enterprise Architecture as shown below:
Taking into consideration the current culture at your university, placing Enterprise Architecture under Information Technology would not make sense. If Enterprise Architecture continues to be placed under Information Technology then at your university Enterprise Architecture would be perceived as an “Information Technology thing”. This perception would defeat the overarching purpose of Enterprise Architecture. Enterprise Architecture needs to have a holistic understanding of your university going beyond Information Technology. A Gartner study (G00245986) supports this thought of Enterprise Architecture going beyond Information Technology as shown below:
From the above figure, we can learn that while technology is a consideration in Enterprise Architecture but it is certainly not the only aspect that needs to be considered. A well-run CORE at your university would consistently produce qualitative and quantitative for both Business and IT. Some of the examples of these are:
Improved Communications Across Organizational Silos
Efficient Portfolio Management
Effective Business Intelligence
1.4.3 What are the Maturity Levels for Enterprise Architecture?
According to a Gartner study (G00252206), it outlines the five levels of Enterprise Architecture maturity shown below:
What this means is that a lot of work needs to be done in this area and your entire university has to be involved in it so that it can be used effectively across organizational boundaries.
1.4.4 How will CORE Measure its Success?
From an operational perspective, a Gartner study (G00247593) indicates the following ways to align Enterprise Architecture to strategic business initiatives:
At your university, the success of Enterprise Architecture would depend upon how it can help your university transform itself to achieve its strategic visions.
1.5 What are the Educational and Research Perspectives?
1.5.1 Is Enterprise Architecture Taught at Your University?
Are Enterprise Architecture courses taught at your university in various schools (e.g., business school, engineering school, professional studies school, etc.)? If yes, do you know if these schools at your university are talking to each other about Enterprise Architecture? If not, then there is no comprehensive Enterprise Architecture program at your university. From this observation, we can decipher that although Enterprise Architecture might be part of certain programs but overall it is fragmented at your university.
1.5.2 Why Should Your University Teach or Do Research in Enterprise Architecture?
In order to be an elite institution, your university needs to look at what other elite institutions are doing, assess what programs they offer and what kinds of research they are pursuing. Your university should then look at how these programs can be stood up.
For the purpose of this article, we will only focus on the institutions that teach, conduct research and/or have comprehensive programs in Enterprise Architecture. These include:
Massachusetts Institute of Technology
Pennsylvania State University
Due to the importance of Enterprise Architecture as a catalyst in organizational transformation, in the current culture at your university, CORE should not be under IT. CORE’s mission is to help your university continuously evolve, conduct/use research and provide comprehensive educational programs. It should be an interdisciplinary entity whose members include all schools, divisions, and departments of your university. Thus, it should be placed where it has the most influence as shown below:
CORE should start as a chartered center initially led by the School of Business and in collaboration with Engineering School, Professional Studies School and IT. Within the first year, this would develop relationships across all the universities.
CORE’s leadership should be on a rotating basis where each school, department, and division of your university has the opportunity to lead CORE for at least 1 year. This will create an atmosphere of collaboration and help break down organizational silos. This governance structure would also encourage participants to be actively involved in CORE’s advancement and they can use it to also enhance their own schools, divisions, and departments.
In regards to education and research, CORE should develop a graduate certificate program with the goal of creating a Bachelor’s, Masters and executive programs in the future.
Tarek M. Khalil; L.A. Lefebvre; Robert McSpadden Mason (2001). Management of Technology: The Key to Prosperity in the Third millennium: Selected Papers from Ninth International Conference on Management of Technology, Emerald Group Publishing, pp.164
This article provides in detail the elements of an Enterprise Architecture (EA) framework that would be selected and deployed at a fictional United States (US) Federal Government contractor called FedCon. FedCon is divided into 3 Business Units (BUs) that are focused on providing Management Consulting, Information Technology (IT) Consulting and Systems Integration (SI) Services in Healthcare, Environment, and Finance.
This article analyzes FedCon in terms of Strategies, Politics, Innovation, Culture and Execution (SPICE) as shown below:
CEO, COO, and CIO
BU SVPs, PMO and program/project managers
Technology products and services
Employees directly interfacing with customers
Technology products and services
PMO, HR and Accounting/Finance
Leverage the massive intellectual property
Based on the above, it is determined that The Open Group Architecture Framework (TOGAF) would be the appropriate EA framework at FedCon since (1) it is supported by multiple vendor tools (2) it is constantly being improved upon and (3) it has an Architecture Development Methodology (ADM) which can be used as a guide.
FedCon is a fictional 30-year-old large publically traded US Federal Government contractor that provides Management Consulting, IT Consulting, and SI services to civilian agencies. It has over 5,000 employees nationwide and it is structured into three Business Units (BUs). Each BU has domain expertise in Healthcare, Finance or Environmental information systems. This structure allows the BUs to work directly with the civilian agencies based on their missions. Each BU has its own account/business development (BD) team that reports to the BU Senior Vice President (SVP). The Program/Project Managers report to the BU SVP and provide status updates on programs/projects to the corporate Program Management Office (PMO). The PMO conducts weekly meetings to provide guidance on corporate standards, compliance, and general project templates.
Over the past couple of years, FedCon has lost 20% of its business. The CEO has been under pressure by the shareholders to turn the company around. Thus, the CEO hired a management consulting firm to determine what were the pain points within FedCon that were preventing it from staying competitive in the marketplace. The management consulting firm’s report revealed that due to inefficient business processes and outdated technologies FedCon’s BUs were not able to collaborate efficiently to manage business and technology changes. Based on these findings in the report, the CEO mandated the Chief Operation Officer (COO) and Chief Information Officer (CIO) to work together to find areas that they can improve in the next 12 months.
In order to address the CEO’s concerns, the COO and CIO came to the conclusion that in order to help FedCon create a disciplined approach to managing strategic intent and its execution they had to look into the field of Enterprise Architecture. Thus, the COO and CIO decided to standup an Enterprise Architecture Program Management Office (EAPMO) that would report directly to the CIO. Initially, the EAPMO is tasked with determining the high-level criterions to select a framework. This task includes providing elements of the framework to be used and how the framework would be applied within FedCon..
In this article, we assess the feasibility of an EA framework that can be used in FedCon by making observations about Strategies, Politics, Innovation, Culture and Execution (SPICE) factors. These factors would focus on understanding the people, processes, and technologies at FedCon to create an effective EAPMO.
Strategies at FedCon:
At FedCon, there are multiple levels of strategies that are developed. These strategies include: (1) the corporate strategy determined by the CEO, (2) the operational strategy determined by the CFO, COO, and CIO, (3) the BU strategy determined by the BU SVPs and (4) the PMO strategy determined by the PMO office. This is shown below.
As we can see from the above figure, each strategy layer addresses different domains for the various stakeholders. Even though these strategies are developed to increase the bottom line and decrease costs, they are created in isolation. Additionally, since each BU is somewhat autonomous it can create technology products and solutions for the civilian agencies that overlap with corporate products and solutions. This is a problem since not leveraging the corporate assets where applicable for client delivery can result in program/project delays and duplicative systems.
The primary strategic concerns in choosing an EA framework are:
Stakeholders – CEO, COO and CIO are the strategic stakeholders and the executive sponsors of the EAPMO.
Domain – Strategically, FedCon is interested in the alignment of business and IT operations and efficient processes.
FedCon has never stood up an EA practice and thus it would be wise to select an EA framework that could guide them in what to do and that it has been proven in the industry to be useful for organizations that are just starting out their EA journey. These high-level strategic criterions are fulfilled by The Open Group Architecture Framework (TOGAF) that provides an Architecture Development Methodology (ADM) as a step-by-step guide and includes how to do stakeholder management.
Politics at FedCon:
Generally, when we talk about politics in an organization we are referring to the negative connotations attached to it. But for our purposes, we will define politics to mean the formal power or informal power of an individual or group within an organization. The power exhibited by these individuals and groups can turn into obstacles or support to bring about organization-wide changes. In this sense, here we refer to formal power as the reporting structures while informal power refers to the influence yielded based upon the size of the BU, revenue generated by BU, the headcount of BU and close relationships of BU leadership with the executives.
At FedCon, even though the BU SVPs have the same title, they don’t have the same power. Taking this into account and the emphasis by the US Federal Government Executive Branch to focus on healthcare issues, the largest and most profitable among the FedCon’s BUs in the healthcare BU. Due to this reason, healthcare BU SVP has more informal power among its peers. This means that if the healthcare BU can be convinced of the merits of the EA practice then we can come one step closer to a FedCon-wide EA practice.
The primary political concerns in choosing an EA framework are:
Stakeholders – BU SVPs, PMO and program/project managers are the political stakeholders. The BU SVPs have the formal power to bring change within their respective BUs. The PMO is a well-established office and it has visibility into the various kinds of projects and has informal power by pushing down changes to the project level within different BUs. Lastly, the program/project managers within BUs are stakeholders as well since they have to indoctrinate their teams on how EA can be used as leverage when developing client technology products and services.
Domain – Politically, agreement, collaboration, and coordination across BUs and the corporate team seems to be the area of focus to rapidly bring technology products and services.
Due to the “friendly” competition among BUs to become bigger and yield more influence in FedCon, politics has to be carefully considered. Sometimes BUs are not willing to share if there are possible overlaps with what they are developing and what is already available in a different BU or at the corporate level. Convincing BUs to work together could be hard and caution has to be taken in which players to involve in the development of the EA practice. Additionally, there has to be some sort of collaboration between the EAPMO and PMO for lessons learned and organizational improvements. These high-level political criterions are also fulfilled by TOGAF where it recommends how Architecture Governance and Architecture Boards should be set up.
Innovation at FedCon:
Broadly speaking, innovation in organizations is disruptive, incremental or a combination of both. Disruptive innovation as described by the world-renowned management theorist Clay M. Christensen’s institute is such that it “transforms an existing market or sector by introducing simplicity, convenience, accessibility, and affordability where complication and high costs are the status quo.” This disruption can come in the form of unique business models, products and/or services that can give rise to new industries and improve existing industries. On the other end of the innovation spectrum, incremental innovation is where small changes are made to existing business models, products and services to improve existing industries.
Being a US Federal Government contractor, innovation at FedCon is mostly incremental since it tries to improve upon its existing products and services that are provided to the civilian agencies. FedCon accomplishes incremental innovation by obtaining customer feedback and assessing the competitive landscape. However, since BUs only focus on their own expertise, there are fewer opportunities for collaboration across BUs, which means technology products and services, are being developed without leveraging what already exists in the organization.
The primary innovation concerns in choosing an EA framework are:
Stakeholders – FedCon employees that work directly with customers are the stakeholders that need to be considered since the improvement of existing technology products and services are highly dependent upon customer feedback and conveying of the feedback to FedCon.
Domain – In terms of innovation, FedCon is interested in creating technology products and services that meet customer expectations and exceed what the competition can offer.
EA is a disciplined approach to accomplishing enterprise objectives through alignment between business and IT. This disciplined approach can also be leveraged to make FedCon more competitive, which can result in bringing technology products and services quicker to the marketplace. This high-level innovation criterion also points towards using TOGAF since it is constantly being improved upon based on the feedback from technology vendors and solution providers.
The culture at FedCon:
The “father of modern management” Dr. Peter Drucker once said that “Culture eats strategy for breakfast.” Culture can affect the ability of any organization to adopt or resist changes to the organization. While culture is typically considered a fuzzy attribute of an organization but there are tangible things that we can observe to decipher corporate culture which includes (1) corporate values, (2) employee recognition and risk-taking, (3) salaries, commission and hourly rates, (4) location, (5) clothes and (6) domain expertise and product/service subcultures.
At FedCon, the culture is such that change is welcomed as long everyone who is affected by it understands its purpose and there is no disruption to normal business processes. This is a two-pronged issue for the selection of an EA framework since even if the value of EA is understood by senior leadership but it is not understood at the BU, program/project and individual levels then it becomes just another information collection exercise.
The primary cultural concerns in choosing an EA framework are:
Stakeholders – FedCon has a process-driven and metrics-monitoring culture. This is one of the reasons that the Program Management Office (PMO) is an important part of FedCon since it provides a consistent process by which programs/projects can be evaluated. In order to incentivize employees to change their behavior for the organizational transformation, human resources and accounting/finance offices are also stakeholders in EA success.
Domain – Culturally, FedCon is interested in creating an atmosphere that encourages employees to take risks and leverage the massive intellectual property it has developed over the years to stay competitive.
One of the reasons for the success of the PMO within FedCon is its process-driven culture. So for the selection of an EA framework, we have to consider what plays into strengths of FedCon. This high-level cultural criterion leads us to TOGAF that provides a methodological approach for EA within an organization. The EAPMO would make use of lessons learned from the PMO to create a successful EA practice.
Execution at FedCon:
Intention without execution is simply thoughts without results. An organization can have great intentions but if it does not operationalize those intentions then all the strategy discussions and documentation it did just an exercise in futility.
At FedCon, execution has two views. One view is the execution based on winning a government contract to deliver technology products and services. The second view is the execution of the corporate strategy that looks into entering new markets, mergers and acquisitions and creating superior technology products and services.
The primary execution concerns in choosing an EA framework are:
Stakeholders – All employees of FedCon at every level are stakeholders in the successful execution of EA.
Domain – In terms of execution, best practices have to be applied/created for all of FedCon and metrics developed that assess organizational performance.
STANDING UP AN EAPMO:
After assessing the business environment of FedCon to determine an appropriate EA framework, next we have to determine people, processes and technologies needed to standup the EAPMO. These needs are discussed below:
In order to assess the skill sets needed to run the EAPMO, we have to look at the current skillsets available, skillsets that people need to be trained on and hiring people with the necessary skillsets at FedCon. The hard skills needed to join the EAPMO require the knowledge of the chosen EA framework (i.e., TOGAF) and the ability to find common themes to enhance collaboration. The soft skills needed to join the EAPMO require (1) being politically aware, (2) ability to create bridges/connections and (3) high emotional intelligence. Additionally, metrics will be created to evaluate EAPMO team members based on their hard and soft skills.
The business processes followed by EAPMO would be determined by TOGAF best practices and what has worked within FedCon. At a high level, this would be the architecture governance process and at the lower level, this would the cross-functional team’s processes for being advocates and collectors of information across FedCon. The various processes would be tested in the first 6 months to work out any wrinkles and get a baseline understanding of what needs to be done.
Now that we have selected the FedCon’s EA framework to be TOGAF, we have to select a tool that supports this framework. This tool can be selected by looking at Gartner’s Magic Quadrant for Enterprise Architecture Tools.
Due to FedCon’s expertise as a technology company and for all the reasons stated in the analysis section, TOGAF is the right EA framework since it provides a roadmap of what needs to be done. One thing to keep in mind is that a framework needs to be flexible enough so it can adapt to changing organizational needs rather than the organization becoming a slave to the framework.