Architecture Teams

In the Dragon1 open EA Method three levels of architecture teams are recognized. On this page, we elaborate on the differences between those teams, their roles, and responsibilities.

The three levels of architecture teams are:

  • Level 1. - Project Oriented Approach of EA – Ad Hoc / Unstructured Change
  • Level 2. - Process Oriented Approach of EA – Managed Change
  • Level 3. - Product Oriented Approach of EA – Controlled Change

One could argue that there is also a level 0 - Not working with architecture. And a level 4. - Continuous Improvement.

With the information on this page, you can also score at what level and what side of the level you are now with your organization.

What is an Architecture Team?

An architecture team is a group of people with the roles or positions of an architect. A team often has a team manager or lead architect. If not, the team has often a departmental manager, like an IT Manager, CIO, or CIO Office Manager.

In an architecture team, the roles can be divided into areas of architecture, domains of concern, or types of working.

Dragon1 prefers to have at least one EA, BA, IA, and TA present as roles in an LME organization.

Not all architects working in an organization have to be internal. For the design of solutions or expert knowledge, it is wise to use external architects. However, it is best to have those architects on the payroll for strategic work, high-level architecture, or creating reference architecture.

Services Menu, Portfolio and Working Schedule

Dragon1 advises every architecture team to define a service menu for their stakeholders / internal clients and to organize their work with a working schedule. In this way, the architects can do their work much more efficiently, especially if there is a shortage of resources.

On the schedule, three types of work are always present: Planned Work, Project Work, and Ad Hoc Work. Every week, you need to be able to work on your general models and documents to make sure you, as a team, can use the same baseline and can advise the clients using a solid foundation in the projects.

No week will pass without any sudden issue needing immediate attention. Every architecture team needs a schedule to have this all occur in an orderly manner.

To have stakeholders / internal clients request products, architects better create a portfolio so it can be communicated very easily what clients can expect when they need a product or use a service.

Level 1. Project-Oriented Approach of EA – Ad Hoc / Unstructured Change

In this level, architects are organized in the following way:

Architects are part of various business departments and IT teams. There is no centralized architecture review board, and architects participate in projects and work for project managers/program managers.

'Architect' is not a position but a role. Architects mainly review the work of others and produce documents that contain a mix of plans for approaches, requirements, and designs instead of splitting them up into three. Architects follow change instead of managing and controlling change. There are no complete or correct Enterprise Architecture documents. There are some project-oriented / solution architecture documents. Architecture is done at an operational level, ad hoc.

The word architecture often gets confused with infrastructure and IT. Many discussions are taking place about what architecture is and why it is. There are no standards to work with; methods and approaches are used at will. The added value of working with architecture is often not (widely) recognized.

Architecture is something people find annoying: architects are only coming up with smart remarks or suggestions too late, too little, and afterward. No Landscapes, Roadmaps, and Blueprints are used in meetings and projects. The architects work mainly for themselves.

Level 2. Process-Oriented Approach of EA – Managed Change

In this level, architects are organized in the following way:

One corporate architecture team is positioned within or near the IT department. Architecture is done at an operational and tactical level. Architects do not yet focus on creating standard architecture products but on executing activities like analyzing, consulting, and advising. They create unstructured PowerPoint presentations, Excel sheet repositories, and unstructured work documents containing architectural design fragments.

There is a notion of Enterprise Architecture, but the various architectures in the framework are not documented (well). There are some standards to work with, but not everything may be used at will. Architects guide Change. An architect is a position. Architects and Project Managers are in each other’s way.

The architects sometimes leave their ivory towers. The added value of working with architecture is recognized but not tangible. Enterprise Architecture is IT architecture that helps implement IT strategy. There are some Landscapes, Roadmaps, and Blueprints in meetings and projects.

Level 3. Product Oriented Approach of EA – Controlled Change

In this level, architects are organized in the following way:

There is one team called 'The Design Office', positioned underneath the CFO or CIO. Architecture is done at an operational, tactical, and strategic level. Architects create (agile) designs for strategy, enterprise-wide (business / IT) solutions, and (digital) transformations.

There is a centralized architecture review board and architecture steering committee. Architects do not participate in projects, but on top of projects, project managers/program managers work for the architects. The architect is the supervisor of realizing a solution with the architecture applied. Standards are enforced. Every architecture dossier is documented fully and compliant. Architects are in charge of Change.

The architects are very often out of their ivory tower. The added value of working with architecture is recognized and tangible. Enterprise Architecture is the bridge between Strategy and Transformation. Architects create effective and beautiful Landscapes, Roadmaps, and Blueprints. These are used in every meeting and project to support decision-making.

Architecting Solutions

DEMO: Concept Mapping Software

How to use Dragon1 EA Tool

Learn to generate architecture diagrams using repositories
DEMO: BPMN Onboarding Process Example

DEMO: BPMN Onboarding Process Diagram - Measure Rules Compliance

Manufacturing, Financial Solutions
DEMO: Enterprise Architecture Blueprint Template

DEMO: Generate an Enterprise Architecture Blueprint to discover and solve RISK

Banking, Logistics, Healthcare
DEMO: Process Application Map

DEMO: Generate Landscape for RPA AUTOMATION

Government, Logistics, Banking
DEMO: Strategy Map Template

DEMO: Generate Strategy Map on how to INNOVATE with AI

Automotive, Financial Services, Health Care
DEMO: Data Mapping Software

DEMO: Generate Application Portfolio Diagram

Retail, Agriculture, Energy, Oil & Gas