EA Shop Management

In many organizations the need for EA shop comes and goes. Usually a new CIO wants to make a mark by invoking a transformation initiative that needs EA to plan a roadmap. Sometimes a push into new technology like cloud adoption requires some EA work to consolidate the CSPs. Starting and restarting the EA division is a reoccurring theme in the discussions.

The common understanding is that, regardless of the prescribed by the EA framework the structure and roles of EA shop, every time it is going to be different. The needs and budget are different, and Chief EA is different and has personal subjective view on how to run the shop, etc.

Here is a structure of the EA shop that I discovered after working in different agencies. It never explicitly like that. But the flows of work done do follow that structure. I call it the implicit architecture, which is unconsciously followed.

The Chief Architect is getting architecture work requests, and conducts EA marketing, develops some sort of EA Plan and makes a decision about the EA Framework to follow. Here come also different ad-hoc “hot potatoes” and “fires”.

EA PMO is getting “killed” by Agile and Kanban. The lack of planning is compensated by the mediocre budget and minimum resources.

Most EAs perform EA Development tasks: defining EA model dimensions, identifying data sources, collecting data, cleaning the data, and visualizing it. Most of work is AS-IS discovery. Some architects trying to focus on a single domain, others are cross-domains. Security domain and network architecture are the most specialized.

Some architects help IT projects, provide guardrails, talk to the vendors, work with developers. In some orgs such work is a big deal, in others not so much. It comes with the common confusion of EA with the Enterprise-wide Solution Architecture which is much easier to understand because it is tangible.

One interesting role is to support the EA Repo. It can include running the hosting VM to making the customizations or even writing custom reports. In most cases this is a developer role, but sometimes there is no explicit EA Framework, so the EA Repo Admin is the real EA job, deciding on the metamodel changes. For some reasons many people view the EA Repo as a EA itself that magically does all the data work by “automation”.

Pretty much everyone in EA shop provides EA Data Call reports from time to time. The idea of a dedicated EA Service Desk is implicit. No case management, usually.

The big deal is to hire consulting services like Gartner to do some real work. In the worst case scenario the vendor provides the roadmap with own technology to sell. The delegation of work further complicates roles and responsibilities. It also undermines the confidence in EA members competence.

The proposed EA shop structure helps to make invisible visible, and plan ahead for the future work and roles, including negotiating EA budget. The flexibility and adaptability of an EA shop does not mean there is no stable architecture behind it.

Technology Management

While the CIO focuses on IT Systems, the CTO role is to innovate with technology. Gartner developed a Hype Cycle Methodology for emerging technology that allows to discover the trends, and provide the governance structure on the enterprise level around adoption of disruptive technologies.

At the same time the CTO is evaluating the existing Technology Portfolio, and manages it in order to limit the duplication proliferation in terms of separate licenses for the same product or service, and diversity of products with the same functionality. It promotes cost saving and cost avoidance.

Technology also poses some risks. Every new product and vendor, including a supply chain, should go through the assessment process from accessibility, vendor support lifecycle, and cybersecurity viewpoints.

One way to manage all of these is by establishing an IT Asset Management capability. IT Infrastructure Library (ITIL) provides an example reference model. The idea is to define the lifecycle of the IT asset, and manage every change in an integrated manner.

To reach that goal several things should happen:

  1. The enterprise should publish the IT Asset Management policy.
  2. The ITAM solution platform should be selected and made operational.
  3. All ITAM functions should use the same ITAM solution platform in order to avoid integration issues and data duplications.
  4. All technology products should be standardized in terms of the naming convention and the vendor lifecycle. The idea is to make everyone in the organization to use the same shared vocabulary.
  5. The Approved Technology List (the whitelist) should be established and published.
  6. Every server and device should be continuously monitored for compliance with the Approved Technology List.
Figure 1. IT Asset Management System Architecture

A popular ITAM solution platform is ServiceNow.

One way to standardize the product names is to use Flexera Normalize application. It allows to replace different variations of the names for the same product version with the only one. In that case the IT Asset Inventory will be clean from duplication.

The get the vendor product lifecycle data, Flexera Technopedia database offers the single point of reference. It relies on the standard names from Flexera Normalize.

One way to ensure that the organization has a mature ITAM capability is to place an IT Help Desk request. If you are an employee with the device given by the organization, the IT Help Desk should know what is the name of your device, and what is installed, and what licenses you have – at the current moment.

Usually the Technology Portfolio is managed as part of the Enterprise Architecture Portfolio. It allows to track which applications are using which technology, and which capabilities are using which applications.

Technology Insertion should come from the projects and from the emerging technology governance. One way to attract potential investments is to establish enterprise platforms for experimentation and pilots, where projects can play before they buy.

The idea is to define the Target State of Technology Portfolio, and gradually modernize existing applications toward it. The best way is to use Application Portfolio Management together with Technology Modernization and Data Management. A good example is a move to the cloud. If it is not well planned, the IT projects will create the same complexity in the cloud as it was before. The same with adoption of RPA or blockchain. The cost saving is not easy to get without cost modeling and strategic planning.

While Business is driving the needs for IT support, disruptive technologies also became the driver that challenge the traditional business processes and offer remarkable benefits to the organization, if applied correctly.

Data Management

The CIO position was defined around Information domain, but in practice the CIO became responsible for IT systems. The new attempt to get to the Information domain was introduced as a CDO position – Data focused. In reality, it all is together – data and IT systems, as well as cloud platforms.

The President’s Management Agenda (PMA) defined the CAP Goal 2 Leveraging Data as a Strategic Asset [1] as leverage data to grow the economy, increase the effectiveness of the Federal Government, facilitate oversight, and promote transparency. This goal is supported by the Federal Data Strategy [2], including Practice 6 Convey Insights from Data: Use a range of communication tools and techniques to effectively present insights from data to a broad set of audiences. 

EA role is to develop a strategic plan, a target state, and a roadmap of IT projects. The target state should be cost effective, and reuse existing IT systems and cloud platforms, as well as consolidate multiple duplications.

There are many components in the Enterprise Data Management architecture.

Figure 1. BI System Architecture

First, EA needs to define the requirements for the executive dashboard, the KPIs. What kind of questions and answers stakeholders are looking for?

Based on that expected outcome and output, EA determines what are the data needs and BI capabilities needs. There are three temporal dimensions: the past (retrospective), the present (operational) and the future (predictive).

Second, EA defines data standards for the whole enterprise to follow. Those data standards should support the defined KPIs. For example, if the executive dashboard has a geographical aspect, then data standards should include geospatial data standards.

The biggest challenge is to establish a data stewardship culture. Every System Owner should have a training in data management, data modeling, and data analytics. They need to understand how data can help to solve the business problems, and why it is important to follow the data standards and data management plan for own IT system in order to achieve the enterprise data management goals.

When the data management culture is followed, then IT systems and databases need to be refactored to follow the data standards. In agile manner, it takes several increments and several releases in order to avoid breaking the dependencies.

When data is standardized, EA needs to establish an Enterprise Data Asset Catalog. Each data asset has to have just one authoritative data source. It takes time to discover different duplicates and consolidate them. EA discovers and documents data lineage in a CRUD matrix.

Every data asset needs to be categorized in terms of Business Objects. EA use bottom-up approach to document the existing standardized Physical Data Model, and then abstract it into Logical and Conceptual models. After that EA, based on the Business Capability Model, refines the data models using a top-down approach. These refined data categories are the final Business Objects that are used to tag the data assets in the Enterprise Data Asset Catalog.

The standardized and Data-model aligned data assets now can be fed into the Enterprise Data Warehouse (EDW) which is a Data Lake. If data is jammed into EDW without standardization or tagging, then it is very hard to make any sense out of it using BI tools. BI tools cannot do magic. They produce results based on the quality of data they have. Data scientists can try to cleanse and transform the data as much as they can, but if the organization does not follow the data standards, and data sources are not known, and data assets are not tagged, then the value of BI tools is very, very low.

As the CIO has its own office, own people, the same way the CDO must have its own people, like data scientists who know not just Python, but also modern data management concepts, including DAMA DMBOK, NIEM, and SOA. Data architects should follow the EA Enterprise Data Management Architecture as the overall vision of the target state, and every System Owner needs to report on the IT system alignment to the enterprise data standards, data sources used, and data assets registration in the Enterprise Data Catalog.

It is a long road, but no organization can afford to avoid it. Business, at the end, is its people, knowledge (data), and processes (IT systems).

1. The President’s Management Agenda 2018, https://www.performance.gov/CAP/leveragingdata/

2. OMB Federal Data Strategy 2020, https://strategy.data.gov/assets/docs/2020-federal-data-strategy-action-plan.pdf

IT as Psychological Models

Information Technology (IT) became an inseparable part of our daily life, at work and at home. We know that at this point our devices and software are “hybrids” of the traditional algorithms and re-emerging Artificial Intelligence (AI).

In IT Architecture field we talk mostly about component-based architecture or service-oriented architecture (SOA). We assume that we are talking about software only, and use the same old hardware architecture.

While discussing AI, we finally talking about modeling our brain functioning. There are latest research and publications, cutting edge machine learning algorithms and quantum computing. It’s a bright future like Tesla and SpaceX.

So, what is that about? It’s about our collective cognitive dissonance.

We are still using the same old Turing machine from 1936. All attempts to move to something different had failed. The modern CPU is basically implements the Turing machine concept. We still running Assembler code under the hood. Our chips are made of simple logical elements.

What we had done is added several layers of abstraction to hide our primitive basic understanding of the reality.

We had the cognitive psychology model. Our brain is a set of procedures. All we need to do is to replicate them in C, Pascal, or Cobol.

Since the complexity of the programs increased to the level of difficulty to manage the code, we moved to the object-oriented model. So, a program is a replication of objects (people), who politely asks each other to provide some services, and keep their know-how and data to themselves (black boxes).

And the next level of complexity was solved by modularization into separate components with tight cohesion and loose coupling.

And then we distributed components and called them “services”.

What is the point here? The Computer Science started from the modeling of the language as logic, then cognitive psychology came up with the procedures as algorithms, and eventually the rest was purely complexity management regardless of logic or psychology or neuroscience. The model behind hardware became irrelevant, because the programming models were so easy to change to the point of the paradigm shift for the system and software architectures, and developer mindset.

IT is a mess of many different models.

Why this is important? Because it helps to reflect what we can think as humans in psychological modeling terms.

Let’s take a look at the Business Architecture.

What we see is Departments, Lines of Businesses, Offices that deliver products. It sounds like component-based architecture.

Later we started to see a shift toward business services. It makes sense, SOA.

What a business component or a service does called a business process. Should we call it SOP – Standard Operating Procedure? Or a workflow?

That’s it. An IT procedure implements a business procedure – a basic cognitive psychology model for IT – and for business. Not much of a difference.

Now, Enterprise Architecture aligns Business and IT. Which psychological model should we use to resolve the mix of the different models and make it psychologically easy for leadership, architects, and developers to understand, perform the analysis, and design new business-IT operating environments?

Archimate modeling language, as the only EA-specific standard, operates in SOA terminology. We have a Business Service, which is realized via an Application Service, and supported by a Technology Service. There are no systems, no components, no offices with scenic windows. SOA is well-suited for cloud computing models such as SaaS, PaaS, and IaaS. ITIL promotes IT Service Catalog. This is a beautiful abstraction applied consistently from end to end.

Do people usually think that way? In general I use a phone, not phone services, I use a computer, not computer services, I use a stove, not stove services. People naturally think in terms of tangible things they can see and touch. A service is an abstraction, not a thing – one cannot see it or touch it. Hence components, capabilities, offices. It is funny that business architecture is actually catching up with the more advanced IT models.

There is an article that talks about how these IT models influence how people think and behave. We are a part of this new abstract virtual world now, and we are getting confused by the changing or mixed-up psychological models which are not natural for humans. The same people get to work, and get to manage, analyze and design business and IT. The same is happening with the management theories, which are stuck in-between of micromanagement and delegation to agile. By the way, brainstorming as the daily management model is a way to admit a failure of the existing models.

A good example is Leica M6 film camera. The psychological concept behind it is so simple that users move beyond the camera to discuss the topics of composition, contrast of the image-making. And when Leica moved to the digital era, it preserved the same concepts in Leica M10 and Leica Q, while many, many other companies piled up new models into the cramped digital camera features to the point of total shift of the conversation toward the gear itself, not the image-making.

This is a problem space.

Our business models and IT models went beyond our natural psychological models into an artificial, unnatural, and hard to understand “cultural” “thing”. It needs a clean up.

The solution?

Psychology should define what is the natural, simple, and easy way to understand the world. Business, management, and IT fields should follow those concepts, not to drive them. The new humanistic psychological model, not neuroscientific cybernetical materialism, is the only way to replace the layers and layers of abstractions with the new clean and simple foundation.


FEAF 2.0 provides the Consolidated Reference Model (CRM) for Portfolio Management and Shared Services which is used across the agencies, and provides consistency in investments planning and reporting. At the same time, CRM describes the business capabilities and services, data assets, IT systems, and technology platforms. Those building blocks are not explicitly prescribed by FEAF, and each non-DOD agency is trying to define them in a silo. DODAF, TOGAF and Archimate do provide metamodels to describe such building blocks.

Scott Bernard published an article “The Importance of Formal Documentation In Enterprise Architectures” in the Journal of Enterprise Architecture, August 2009, where he proposed a Metamodel of Artifact Relationships in the EA3 Cube Approach, but it was not included into the official FEAF 2.0.

HHS EA built own metamodel based on the changing guidance and initiatives from OMB which eventually become too cumbersome to maintain. Other agencies share the similar story.

The lack of the standard metamodel creates inconsistency and confusion not only in collecting and storing the EA data, but also in generating reports and getting value out of EA. 

Here I am proposing a draft of the metamodel that includes FEAF CRM and common building blocks. It uses the concepts commonly used in CPIC and Cybersecurity, as well as OMB policy and CIO Council. I used Archimate as a modeling language and Archi as a modeling tool.

FEAF Metamodel

An organization has a set of goals. Each goal has a set of objectives. 

To reach a goal and its objectives an organization needs to define a strategy. A strategy is an approach to change the architecture using different business capabilities and different initiatives. 

Goals, objectives, strategies, capabilities, and initiatives define a Strategic Plan.

To implement a strategic plan, an organization needs to define the Current State of its architecture in terms of its Business, Data, Application, Infrastructure, Security, and Investment domain portfolios.

Next, an organization needs to gather requirements for the Future State. It includes a Strategic Plan, an analysis of the Current State, Department’s Business and IT (IRM) goals, objectives, and initiatives to align to. 

In order to facilitate domain portfolio management, a set of FEAF Reference Models is applied to the Current State in order to identify duplications and gaps:

  • Business Reference Model (BRM)
  • Application Reference Model (ARM)
  • Data Reference Model (DRM)
  • Infrastructure Reference Model (IRM)
  • Security Reference Model (SRM)

After all requirements are identified, an organization develops a Vision of the Future State, and details in the same terms as the Currents State: Business, Data, Application, Infrastructure, and Security domain portfolios.

Next, the Gap Analysis determines the difference between the Future State and the Current State. Those gaps need to be addressed via projects (Projects Portfolio). Projects will be funded by Investments. The list of the proposed investments (Investment Portfolio) will be submitted to the Investment Review Board for approval.

To justify the proposed investments, an organization needs a business case and the architectural description, including a Transition Plan in terms of planned projects and the timeline.

The first step to establish EA in an org is to start managing portfolios.

Application Portfolio contains IT Systems, which are different from the cybersecurity “systems” also known as Security Authorization Boundary (a.k.a. ATO). ATO can have one or more IT Systems.

Application Portfolio enables Mission and Business Services to realize Business Capabilities of the agency.

Technology Portfolio contains Software Product Versions. Each Software Product Version has a vendor support Lifecycle and user licenses. Technology realizes IT Systems. An org can establish an approved list of its Technology Portfolio in order to limit duplicative technology proliferation (IT Technology Standard).

CRM describes different portfolios in order to identify duplication and gaps, and thus enables Portfolio Management, for examples, promoting reuse of the existing technology, and so, limit IT cost.

The shared metamodel across government agencies helps to mature further OCIO capability to manage and align IT to business by providing clarity and interoperability between various tools, helping to speed up time-to-market decision support data, and establishing a consistent common language for executives.


Enterprise Architecture is about how an organization is aligned to its Mission and Vision. A Vision is a high-level sketch while the Architecture is more detailed. One way to conceptualize the architecture and express it through a Vision is to use Business Capabilities.

A Capability is a stable, strategic concept to achieve a desired effect. It is used for Strategic Planning to implement a Strategy. Also it’s useful for briefing leadership, including such concepts as a capability gap and a capability increment. It provides a clear strategic thinking framework without the clutter of the details.

A Vision of the Operations, or the Concept of Operations (CONOPS), expressed via Business Capabilities, allows to quickly grasp what the organization is trying to do, and how it intends to do it. It shows external stakeholders, a supply chain, and internals in terms of capabilities.

Here is an example of the major elements of the CONOPS diagram. It contains the boundary of the enterprise, external stakeholders, and internal capabilities.

Now we can get people on the same page. If we stick to the same common language of capabilities, we can talk about capability gaps, and capability-based planning, and capability increments. We can change processes, applications, technologies while keeping the same capability concepts. Also, we can add or remove capabilities. It’s a simple, high-level, strategic LEGO game.

A CONOPS graphics helps to visualize the architecture of the complex organization, and connect different parts in a meaningful manner. That image-making creates a shared understanding of what is, and what is to be. It creates consistency over time and survives the chaos of the projects.

Now, for each capability or a set of the related capabilities, we can apply a concept of the segment architecture. Each segment is responsible for specific capabilities. A Segment contains program offices and shows a different perspective of the org chart. This way a conversation can continue on the implementation side, and give a proper understanding and a meaning to project managers and contractors on what exactly they are doing.