Enterprise Architecture Services – What is the Value

I got a few comments that the Enterprise Architecture (EA) is just overhead. It's work being done that everyone "just knows", so why waste time on it? As a resource, it is better to use actually producing solutions, buying tools, they say, if they genuinely even understand what Enterprise Architecture is.

Many confuse Enterprise Architecture with Solution Architecture at Enterprise Scale — that is, it is about creating solutions for big companies. That is not Enterprise Architecture, although EA does impact the solution development. EA goes beyond the solutioning of a product and is focused on the structure of the enterprise and its technology. This includes several domains of architecture, including business, applications (including custom, bought and subscribed application services), data and the underlying supporting technologies such as networks, servers, clouds and the devices that hang off of them.

So what does EA actually do then? In my view they provide two important capabilities: They are the librarians for the enterprise and they are sort of the guardians of the IT organization. So what does that leave us with?

First is the Librarian side of things — One of the first efforts when establishing an Enterprise Architecture practice is defining an Enterprise Architecture Repository (EAR). This is the source of truth for the current state of the enterprise. It can come in many forms — from documents to UML models to drawings to data. Following TOGAF, it includes three types of artifacts: Catalog (lists of things) and Matrices (relating a list of things to at least one other list of things). And Models, which provide the documentation and design of a more complex nature.

• Catalogs are simple, but they are the first building block to the other types of artifacts — for example, a list of business processes, employees, applications, or other entities in the organization. These lists would include additional data. An Application Catalog would contain the name, vendor, version and other pertinent information.

• A Matrix ties two or more lists of things together. For example, business processes and employees may define the owners, supporters, users or other relationships that the employee has with the business process.

• A Model would represent a view into more complex relationships — for example, an organization chart, class diagram or a networking diagram. Here there is additional information being shown, such as the flow of data or hierarchies or webs of information.

These artifacts would be maintained in the Enterprise Architecture Repository — the library of all architectural knowledge. The EA's responsibility is to maintain it, ensuring that both potential changes and the current state are maintained. The EAR also contains other information as well, including reference information such as standards and reference architectures,

The other activities of Enterprise Architects should be reflected in the EAR. These other activities can be represented as services — the tasks and processes offered to the IT and business community to ensure alignment between the two (IT and Business) as well as execution of the technologies.

This all starts with defining the principles, vision and requirements and then the domain architectures and finally the realization . . . but what does that really mean and how can you sell the idea of EA with these ideas. I believe the way to do this is through providing an array of services that provide specific value.

Technology Selection — The reviewing and approval of technology are critical for the organization — it is essential to reduce the number of technologies (managing complexity) as well as align technologies with the strategy of the organization. Many organizations waste large amounts of money and time when different technologies are brought in by siloed teams. An EA service like this helps to reduce duplicate technologies. This saves money by reducing licensing costs, reducing integration costs and reducing operational costs.

Proof of Concept (PoC) Development — This is my personal favorite activity out of all of the EA Services. It is the development of a model or system that proves our ideas or answers questions. This is where innovation can be spawned and ideas generated or shot down. This could include developing a system from scratch (i.e., coding), or implementing a trial software downloaded from a vendor. But it could just as likely be a mind exercise — drawing a model that shows the capability based on known facts and assumptions. An important aspect of developing a PoC is knowing what you want to answer. Why are you doing it and what do you want to know once it is completed.

Strategy Development — This is probably the most controversial service and probably the least likely to exist in the wild. Many organizations do not have a well-defined capability to identify the strategy. CxO's like to keep this within their domain as they see this as their bailiwick. But a lack of a rigid process can lead to missteps that can be disastrous. Archimate, a metamodeling tool by The Open Group (the same people who produce TOGAF) can aid in the process. Enterprise Architecture can also assist the CxO in the development of strategy, identifying current states and performing or validating other analyses. One caveat is that business architecture must be recognized as a component of EA.

Governance — Governance is an important aspect of EA. It can be an intensive effort to ensure that systems are being built as expected. It includes developing and/or reviewing designs and being involved in setting the rails and processes through which technology is implemented and deployed.

Roadmapping — Road-mapping is an important part of the planning for IT. The technical roadmap is used to understand future budgets, training needs and hiring demands. But there is another aspect of road mapping that is often ignored within technical organizations — capability road mapping. Capability road mapping is the process of identifying and scheduling the capabilities and the needed improvements in them to meet the strategy. This feeds directly into the technology roadmap (and let's not forget that the tech roadmap has feedback to the capability roadmap). For example, a capability may be to deliver a product within 3 days of ordering. If this capability is needed in one year to meet the strategy demands, but the technology is going to take 14 months to implement, then there is a mismatch on the roadmaps and either a way to deliver the technology needs to be found or the capability roadmap needs to be adjusted.

Process Improvement — Identifying process flows and how to improve them may very well prove to be a differentiator in the market with your competitors. It can lead to advancements and innovations that are critical to the success of your enterprise. EA can provide this as a service, bringing their technical and business knowledge to bear, whereas those who are embedded in the process are too close to it to see the possibilities.

Research — I find that the best architects have a curiosity about them. They are always reading, always exploring, and always pushing boundaries. The research comes naturally to them and they relish the idea of exploring new technologies, new theories, new frameworks or new processes. Research is often more structured in EA, with tasks to identify and answer certain questions. But I firmly believe architects need to have the time to perform some unstructured research as well.

Communication — EA is 50% communication — or at least that is what I was taught when getting my Architecture certification at Volvo EACOE, and I believe it. Architects need to communicate to developers, implementers, businesses and others within the organization. They have the hammer of governance, but the Kidd glove of guidance and persuasion to help align all things technical and business so that strategy can be implemented.

Design — This is the bread and butter of the Enterprise Architect. Designing is what we do. It may be business design (if your enterprise is lucky enough to have a Business Architect) but it most certainly includes technical design of data, applications, and infrastructure at least at a high level.

By providing these services EA can provide a positive impact by aligning strategy and technology — which is where the real value is generated by EA. All of these tasks are ultimately in support of that alignment. I believe that a proper EA organization must include Business Architecture in order to support this critical alignment. The Enterprise Architecture Repository provides a basis for this alignment by maintaining the current state of the enterprise. And the EA's vision and principles provide a lens through which decisions are made. All of these work against the tyranny of the CxO who wants to push their own views, without the rigor of intellectual thought and analysis that EAs bring.

But like Guardians and Librarians, this takes discipline and effort.

Enterprise Architecture Activities are Taken on by Different Roles

EA is not always called EA anymore, but the practice remains highly relevant. Most of today's industry and thought leaders providing best practices for modern EA do not call themselves Enterprise Architects anymore. This is why the practice is perceived as less relevant today.

However, there are new titles and roles that cover Enterprise Architecture aspects, which did not use to be part of traditional Enterprise Architecture models. In addition, Enterprise Architecture activities are often covered by IT architects, which have some IT and some Enterprise responsibilities at the same time. The result is that Enterprise Architecture and IT Architecture become closer aligned and sometimes addressed by one and the same role.

New Enterprise Architecture Management Frameworks

Because of increased relevance and urgency for frameworks and approaches, new players entered the area of Enterprise Architecture. It seems that the structures of the traditional, renowned Enterprise Architecture organizations are too slow to react to the disruption triggered by the Digital Transformation. In consequence, providers of new tools and technologies, especially from the cloud area, develop their own frameworks and approaches to addressing the multiple new challenges of their organizations.

Enterprise Architecture Frameworks are Necessary to Drive a Successful Digital Transformation

Digital developments still trigger regular disruptions and strong growth (e.g., new cloud service providers and supporting technologies). Consequently, there are many newly emerging market players with new and diverse solutions, resulting in a scattered landscape of Enterprise Architecture best practices. Hence, EA is targeted throughout different practices and departments and by different players, such as tool providers, large cloud providers, agile frameworks, organizations, and communities.

The Future of Enterprise Architecture

While in many areas, diverse solutions and competition is beneficial, this is not necessarily the case for Enterprise Architecture — which aims at providing standards and comparability. In addition, the diverse market solutions might make the work of IT and Enterprise Architects more challenging in the future as they need to keep an overview and align altogether.

As a result, the diverse landscape, which developed in recent years, might consolidate and harmonize under a new (or even the old) umbrella term covering key activities and objectives of Enterprise Architecture.