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. But when they see their business consultants (architects) produce blueprints like the one below, Board members and directors get excited and want to use them. They see strategy on the left, architecture in the middle, and transformation (projects & 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 keep programs and projects on the right 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 for mainly 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 next 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) are on the right. This is an architecture diagram because it shows a total concept. On the diagram, you see elements (logical functional entities) in layers that are part of various concepts (they 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, per concept, the elements collaborating 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 realizing fundamental strategic enterprise-wide infrastructure and facilities, although they say they are. Systems analyses and system design, their core, 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 the design AND realization of necessary fundamental strategic enterprise-wide solutions for the business (using 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, but don't talk about 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 concept applied to it (the 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 shows what concepts are present in the organization, at what level of maturity, and how well they perform. Most organizations worldwide do not have such 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 works in a certain way, producing 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 create strategic, sustainable, and competitive systems and solutions for the organization. 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 many different views of his 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 compliant to 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 anymore and only present business solutions to clients, we would achieve much more as a craft.