As a founder of the Dragon1 platform and method and being an Architect, I meet all kinds of people who have never heard of Enterprise Architecture before. However, when they see their business consultants (architects) produce blueprints like the one below, Board members and directors become excited and want to utilize them. They see strategy on the left, architecture in the middle, and transformation projects and deliverables on the right. They think it's great because they understand it, seeing their daily topics. They use the blueprint to support their decision-making, communicate their vision and strategy, and ensure that programs and projects stay on track.
When you introduce the word Enterprise Architecture, Enterprise Engineering, or Architecture Principle, or talk about other aspects of the theory, it all goes wrong. This is mainly for two reasons. Reason 1: the current wrong mainstream notion in the field of what's enterprise architecture (and it is also being continued by many entities that are making money with it). Reason 2: Architecture is a craft and cannot be explained within seconds, and to understand everything that goes behind architecture requires conceptual thinking and experience.
In every training course, I tell Dragon1 users NOT TO USE THE WORD ENTERPRISE ARCHITECTURE anymore. (Like here, the title says Strategy and Transformation on this blueprint.) But what, then, do you say to your clients? Well, tell them the result. Tell them the business outcome. Tell them you are the one who can design and realize the best business solutions they need to execute their strategy. Because without the right business solutions, you CAN NOT execute your strategy. And yes, I say business solution because IT is only part of a business solution.
Using our bizarre word 'Enterprise Architecture' and then having to explain it to clients is a major pitfall. So keep out. A building architect does not use the word 'architecture' and explains it to his clients.
In this diagram, you see Strategy (goals and actions) on the left. Architecture (elements and principles of concepts) is in the middle. And transformation (projects and deliverables) is on the right. This is an architecture diagram because it presents a comprehensive concept. On the diagram, you see elements (logical functional entities) in layers that are part of various concepts, which are hidden in this view. And you see concept principles (the way that elements of concepts collaborate to produce results). In other smaller diagrams, not shown here, called Principle Details diagrams, the elements collaborating per concept are visualized. This blueprint is merely a collection overview of all these diagrams.
As an Architect, you are busy collecting strategy and requirements, selecting concepts and principles that fit the strategy and requirements. You are busy creating business solutions designs where the concepts and principles are applied. However, you only show the client understandable pictures of concepts, principles, and solution designs so they can make decisions. Next, roadmaps and designs are used in projects to build the solutions.
At my clients, I also have this daily problem of 'fighting' against the notion that (the self-proclaimed standards) TOGAF and ArchiMate have anything to do with ea. They are not open, have no ISO registration like BPMN, and are commercial trademarks. TOGAF is an information management framework, and ArchiMate is a meta-model with standard views that aim to improve, rationalize, and increase the integration of business processes and software applications. Of course, that is a valuable thing. However, they are not about designing and implementing fundamental strategic enterprise-wide infrastructure and facilities, although they claim to be. The core of systems analysis and system design is NOT architecture. ArchiMate and TOGAF have confusing and conflicting definitions for concepts. In ArchiMate, there are missing modeling shapes for entities like activity, state, view, model, meta-model, architecture, structure, concept, and pattern. To avoid having to talk about this and explain this to your client, try to avoid using the word ....
Many, many, many architects, unfortunately, think that if they only document process-application landscapes and create abstract enterprise models, they are working with architecture. Creating a document or diagram called enterprise architecture does NOT work with architecture. Any method, framework, tool, or approach is only part of an architectural method if it supports both the design and realization of necessary, fundamental, strategic, enterprise-wide solutions for the business, using established principles.
Analysis, design, and realization of total enterprise concepts and enterprise-wide solutions as part of an ecosystem is Enterprise Architecture. So, focus on producing quality concept sketches, blueprints, principle details diagrams, and roadmaps for the client to make decisions. Just do it, but don't discuss the theory with your client.
I am now going to list the fundamental words to understand what enterprise architecture is. Next, use them in a couple of paragraphs to explain them at a high conceptual level: architecture, structure, total concept, concept, principle, element, component, object, and technical product. Infrastructure, facilities, owner/client, stakeholders, views, (program of) requirements, future state, current state, design, and design contract. Roadmap, blueprint, landscape, concept design sketches, principle details diagrams. All these words are necessary to understand enterprise architecture as a whole. So when a client asks you what architecture is, and if you've only got a second or two, tell them it is for designing and realizing the best-fitting business solutions for a given strategy.
The architecture of a structure is the total concept of a structure, being a coherent set of constructive, operative, and decorative concepts. In short, architecture is a special concept. In enterprise architecture, the concepts are governance concepts, client concepts, business concepts, IT concepts, etc...
Take, for example, a total concept consisting of the concepts: self-service, mobility, zero waste, fridge vegetable cultivation, big data, and virtualization. These could form the total concept (architecture): The Green Employee Food Mobile. And if you apply this total concept to an organization, you will only be doing enterprise architecture.
It is not that you didn't know. Everyone knows that the Colosseum in Rome is a half-open amphitheater. The Colosseum is a structure with a total design concept applied to it, featuring a half-open amphitheater.
In this concepts overview diagram, you see functions per layer and function, a concept applied to it. This is a very abstract diagram. But it is a useful architecture diagram. It reveals the concepts present in the organization, their level of maturity, and their performance. Most organizations worldwide lack a diagram to communicate their current status and level of architecture. So, if you, as an architect, create such a diagram, you will stand out from the crowd.
A concept is an idea, way of working, or approach, and always an abstraction of an implementation (self-service is an example of a concept). Every concept operates in a specific manner, yielding predictable results. This is called a principle. So, if a concept is made part of an architecture, the principle of that concept is an architecture principle. It is as simple as that.
The parts that a concept consists of, are called elements (at logical level) and components and objects (at physical level) and technical products (at implementational level).
An enterprise architect is the designer and supervisor of the realization of infrastructures, facilities, systems, and solutions, making use of / applying total concepts and their principles. Why? This will ensure that the systems and solutions will fit strategically and fundamentally. You will develop strategic, sustainable, and competitive systems and solutions that drive organizational success. You will be able to do this because the requirements you use, for selecting the concepts and principles as part of your architecture (total concept), are formed by the needs of stakeholders and goals and actions as part of the enterprise strategy.
An architect analyzes the current state and designs a future state. To have all stakeholders decide on the future state and make it buildable, the architect creates multiple views of their design, all stakeholder-role oriented. In projects, these views, next to the blueprints, landscapes, roadmaps, concept sketches, and principle detail diagrams, are used to build solutions.
This is enterprise architecture.
If you are an architect and want to do as little as possible to create architecture products (artifacts), then at least list 100 architecture principles and group them into ten enterprise domains. On average, you will have ten principles per domain; some principles will be in more than one domain. Have this list approved by the board or the directors of the company. Only then will your 'architecture' have any status and be used.
An example architecture principle would be: Self Service - By enabling people always to serve themselves, they will solve their issues and make their own choices and pick the things they need, which in the end significantly will lead to removing waiting times, increasing customer experience and increasing throughput and reducing costs.
Note that we have written down a mechanism, not a rule of thumb or normative statement. This principle is formulated in compliance with the Dragon1 open EA Method. Make sure that you can refer to literature for every architecture principle.
Architecture helps you to start at the strategic and conceptual level with your design and realization of a business solution instead of starting at the logical or tactical level. If only architects would never use the word 'architecture' and instead present business solutions to clients, we would achieve much more as a craft.