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 do 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.
The moment 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, on this blueprint the title just says Strategy and Transformation.) 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 also 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) 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 with collecting strategy and requirements, selecting concepts and principles that fit the strategy and requirements. You are busy with creating designs of business solutions where the concepts and principles are applied. But you only show understandable pictures of concepts, principles, and solution designs to the client, so they can make decisions and next to these 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, they have no ISO registration like BPMN and they are commercial trademarks. TOGAF is an Information Management Framework and ArchiMate is a meta-model with standard views, all to improve, rationalize, and increase the integration of business processes and software applications. Of course, that is a valuable thing. But 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 and 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 is NOT working with architecture. In my humble opinion 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 with. Just do, but don't talk about the theory with your client.
I am now going to list the fundamental words to understand what is enterprise architecture and 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 be understood, to understand enterprise architecture as a whole. So when a client asks you what is architecture, and if you've only got a second or two, only 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 total 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. Together these concepts could form the total concept (architecture): The Green Employee Food Mobile. And if you apply this total concept to an organization, only then you will be doing enterprise architecture.
It is not that you didn't know. Everyone knows that the Colosseum in Rome is a half-open amphitheater. You see, 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 very useful architecture diagram. It shows what concepts are present in the organization at what level of maturity and how well they perform. Most organizations in the world 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? Well, this will ensure that strategically and fundamentally the systems and solutions will fit. You will be creating 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 all is enterprise architecture.
If you are an architect and want to do the least as possible on creating architecture products (artifacts) then at least write down a list of 100 architecture principles and group them into ten domains of the enterprise. On average you will have ten principles per domain and some principles will be in more than one domain. Have this list approved by the board or the directors of the company. Only then your 'architecture' will have any status and will 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 and 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.