What are the different types of architects considered for Enterprise Architecture?

Introduction

Today within most of the large organisations, we can find more and more "Architect" positions, without being always sure concerning the associated roles and responsibilities.

This article provides a review of some sources proposing description of these different roles, pointing out convergence and complementarity. For this second version of the article, FEAPO, SAVE and ArchiMate inputs were enrich with Data Frameworks from the Global Data Management Community (DAMA) and Donna Burbank (Global Data Strategy, ltd).

FEAPO careers guide

FEAPO stands for Federation of Enterprise Architecture Professional Organisations.

"Established in 2011, FEAPO is the largest non-profit global association of unified professional organizations dedicated to advancing the profession and stature of Enterprise Architecture.FEAPO was founded by Dr. Brian Cameron, Associate Dean for Professional Master’s Programs and Clinical Professor of Management Information Systems at the Penn State Smeal College of Business, and 9 global professional organizations. FEAPO has grown to 15 member organizations with multiple strategic partners.The mission of FEAPO is to provide a platform – a forum – to discuss cross organizational activities, standardize, professionalize and otherwise advance the discipline of Enterprise Architecture."

FEAPO provides a collaborative platform for member organizations and facilitates cross-organizational programs to create unified perspectives in the maturing and mainstreaming of the Enterprise Architecture profession. FEAPO work groups develop highly cited publications, professional and educational activities, and provide forums for member organizations to present work for endorsement. 

On its web site (feapo.org), some resources are provided such as a taxonomy and a guide to careers in Enterprise Architecture This last document is particularly interesting.

The main provided definitions coming from the taxonomy are:

• Application Architecture: Application Architecture represents the specification and structural partitioning of technology‐based automation into business logic, user experience, and data perspectives as an enabler of business architecture and strategy.
• Business Architecture: Business Architecture represents holistic, multidimensional business views of: capabilities, end‐to‐end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.
• Data Architecture: Data Architecture represents integration of value specifications for qualitative and quantitative variables and their alignment with business architecture and strategy.
• Technical Architecture: Technical Architecture represents the logical and physical interconnection of infrastructure elements to enable the deployment and management of data architecture, application architecture, business architecture, and strategy.
• Enterprise Architecture: Enterprise Architecture represents the holistic planning, analysis, design, and implementation for the development and execution of strategy by applying principles and practices to guide organizations through the integration and interoperation of all other architecture domains.

The motivation of the careers guideline is the following:

"The recently released Federation of Enterprise Architecture Professional Organizations (FEAPO) white paper characterizes enterprise architecture as “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”

The guideline was produced relying on a large community:

"Many large organizations have reached out to FEAPO to create guidance. These companies and agencies have sought clarification on the skills, roles, and responsibilities that the members of an Enterprise Architecture team should demonstrate. To meet this challenge, the member organizations of FEAPO, representing over one million technical professionals worldwide, chartered this Guide and collaborated on its contents."

Also as members, sponsors or affiliate, we can find Global Data Management Community (DAMA), the Business Architecture Guild, the IEEE Computer Society, the Internal Institute of Business Analysis, the International Council of System Engineering (INCOSE) and many others. The Open Group, which produced TOGAF and ArchiMate, is not part of this list.

The terminology used for the guide is the following:

• Capability – An ability that an individual may exhibit.
• Competency – A capability that an individual may exhibit to do something successfully. They may have developed that competency through formal education, work experience, mentoring, or a combination of sources. The Guide is not concerned with the different ways in which an architect may have come by their competency.
• Competency Group – A grouping of competencies that helps to identify gaps and elicit specifics from hiring managers.
• Role – A cohesive set of competencies that FEAPO members have found valuable in their day-to-day experiences. Multiple roles may share particular competencies; overlap of roles is common. Note that a role is not a description of a person. Not only can a single person perform multiple roles, they can perform them simultaneously. In other words, it is perfectly appropriate for an architect to be performing the role of an information architect and a business architect at the same time, in the same conversation or meeting, or while creating a single deliverable for stakeholders.
• Level – The degree to which an individual is proficient in a competency. In order to describe the competency of an enterprise architect, it is not enough to say that a particular architect “has” a competency; an individual must be able to illustrate the level of proficiency in that competency for a given role.

Enterprise Architects

• Enterprise Architect specific competencies are analytical thinking, architecture, finance, management, influence without authority, communication, interpersonal skills and leadership.
• Enterprise Architect is considered as a senior role, while some other kinds of architects are considered as mid-career roles: business architect, information/data architect, application architect, technology architect and security architect.
• For each competency, a set of sub-competency are proposed for which levels are provided per role: follow, assist, apply, enable, ensure/advise, initiate/influence, set strategy/inspire/mobilize.
• In particular, architecture competency includes design, information analysis, modeling, process improvement, road map development, scenario building, standards development, system development and system integration.
• Management/leadership competencies include project management, life cycle management, Enterprise change management, Information Management, Risk management, Project Portfolio Management.

The detailed table of expected competency level is the main differentiator between the different kind of architects provided by the careers guideline, and not the association to some artefacts with RACI matrixes as made for methodologies, or dedicated viewpoints as defined by ArchiMate.

The guide also indicates the different kind of team structure patterns, and suggests the kind of questions for an interview.

ArchiMate

ArchiMate is an enterprise modeling language standardized by the Open Group.

It provides the definition of a set of modeling constructs, with modeling concepts (entities and relations) and associated visual language. It is structured according layers/areas. The model and visual model representation are clearly separated. Visual representation is considered as a set of views, which can be structured relying on viewpoints. The viewpoints are associated to stakeholders, concerns and subset of constructs to be used.

Here is an illustration of roles considered for the viewpoints, enriched with some complementary roles I needed for usage in past projects:

The actors are concerned by some of the viewpoints defined by ArchiMate 3, and illustrated as following:

Let's not that the first illustration is based on ArchiMate 2, and the second on ArchiMate 3 with indication of viewpoints which were removed. It is so important for this article, what matters is that it reflects the concerns (related to the viewpoints) and kind of business objects (e.g. business process, network, etc.) the different architects are dealing with.

Unlike methodologies, no artefacts are defined with definition of responsibility with RACI matrixes. I personally think that the viewpoints should have a reinforce role and that a first basic set of them should be normative, even if it required for each specific organisation to be able to extend or to tailor them. This is developed on the article "PLM interoperability: the potential of ArchiMate viewpoints".

So as for FEAPO, we can find enterprise architect, business process architect, information architect (with a dedicated viewpoint) and technical/ICT architect. Security architects don't have dedicated viewpoints, but they have to consider all the layers.

As stakeholders are also considered, with their dedicated viewpoints, it also indicates which kind of collaboration should be established with usual roles for architects, and what could be the added value of architecture for these roles .

As PLM interoperability is one of my main concern, I added specific stakeholders for PLM: the domain architects and product developer. It is the starting point of the Federated Interoperability Framework I've been developing during my research activity the last years.

But are the emerging agile trends impacting the architects roles?

SAFe

SAFe is one of the agile methodology as scale currently available.

It provides a methodological framework. Considered architects are system architects, solution architects and enterprise architects.

Unlike FEAPO or ArchiMate, for each role, a description is provided including a set of tasks/activities they are responsible for. The description is consequently more "methodology" oriented. It corresponds to the way a methodology is usually described, as reflected by the Software Process Engineering Metamodel (SPEM).

Also, we can see that no architect is part of a SCRUM team. Considering that SCRUM initiated for software development, it can be explained by the fact that developers are very often ignoring modelling and that software architects are considering more the architecture of the code as something to build dynamically through code reengineering, with emergent architecture. However close collaboration with new ways of working are required between architects and Agile teams, which could rely on model based approaches (cf. Agile: from Drawing to MBSE/Enterprise Models with SPEM? ).

Data Governance

This section relies on Data Frameworks from the Global Data Management Community (DAMA) and Donna Burbank (Global Data Strategy, ltd).

DAMA International is a not-for-profit, vendor-independent, global association of technical and business professionals dedicated to advancing the concepts and practices of information and data management. It have been providing a Body of Knowledge, plus training and certification programs. The Body of Knowledge provides a framework for setting up Data Governance within the enterprises, and considers 11 domains of knowledge as illustrated by the following figure (Source: DAMA International 2012, www.dama.org)

Note: some changes occurred in the last version of the DM-BOK)

Such a framework is used by many consultants, trainers or solution providers (e.g. Collibra).

Global Data Strategy is an international information management consulting company specializing in the alignment of business drivers with data-centric technology. Its headquarters in Boulder, Colorado, is an innovation hub for data management and information technology, with staff around the world with expertise in data management disciplines as well as vertical industries such as energy, telcom, financial services, and government. They offer training services including Enterprise Data Strategy, Data Governance, Big Data Analytics & Business Intelligence, Master Data Management (MDM), Data Quality and Data Architecture & Data Modelling. Donna Burbank, the Managing Director, have been publishing many high value presentation on slide-share (I recommend to have a look at it), with an interesting way for representing the associated landscape represented in the next picture.

This highlights what are the the different domains of knowledge for a data architect and the enterprise landscape where they operates.

Coming back to FEAPO, the different competences they should have are describe, which for each an associated level (follow, assist, apply, enable, ensure/advise, initiate/influence, set strategy/inspire/mobilise). The competences were they have the most important positioning are information analyse, insurance and management. But referring to the landscape, they should also have an important set of soft kills and abilities to contribute or support the Data strategy and the alignment with the Business Strategy. Also, an important set of technical skills are required considering the two lower layers of the landscape. This is reflected on FEAPO guide.

If referring to ArchiMate, the Information/Data architect have a dedicated viewpoint, allowing to capture Business Model elements and their representations linked to the application layer (Data objects, application controlling them, associated services producing or consuming them and artefacts realising them, distributed on the technical infrastructure.

If always pointed out by the Data Governance should be related with Enterprise Architecture, one potential difficulty comes from the fact that the proposed approaches are often highly Data centric: the term "data" is everywhere. So it is sometimes difficult to know what differentiate what is described at the different layers, as done by ArchiMate. As I've been working in the area of Manufacturing Data open standards for Product&Process data exchange, sharing and long term archiving for years, I'm also not fully satisfied by the terminology used by ArchiMate, in particular with Data used at applicative layer. For me, the most appropriate denominations, coming from the ISO STEP standard for Product Data Exchange, Sharing and Long Term archiving, are knowledge, Information and Data. Data realise Information, so should be at the technical layer, as a particular subset of ArchiMate artefacts. Information corresponds to what ArchiMate calls "Data Objects". It needs to be understood by users, implying that it comes with a well defined semantic, which will drive the ability of applications to share or exchange them. It is the purpose of the "Application Protocols" provided by STEP. The information is relevant within the business only if contextualised and bringing value to those producing and consuming them. It is always related to decision making, in order to respond to the objectives defined for achieving the goal of the enterprise. It corresponds to the ArchiMate Business Objects and to their representations considered by the business.

The "Data Centric" community is probably considering a body of knowledge which is richer concerning the kind of data assets and technologies which can be considered today, compared to Enterprise Architecture. However, there is some weakness concerning how to easily link it with Enterprise Architecture: how to combine Data governance with Service Oriented Architecture or Process Framework? Considering Manufacturing Data Standards and Product Lifecycle Management, the link is weak when considering Product Digital Models and their modern implementations for usage in cyber-systems or as digital twins. PLM concerns processes for producing and exchanging Product and Process data all along the phases of the lifecycle of a product (sometimes more than 100 years) and within the extended enterprise. If not easy to map with general Data Governance Framework, it is also difficult to capture with ArchiMate, due to the fact that Open Group is often more Service oriented, with a weak experience concerning Computer Aider Design and Production for the manufacturing domain. If important overlapping and similarities, the framework of each domain has some weaknessess for the other domains, making it difficult for each of them to be the single framework to be adopted. It also makes the combined usage of the framework uneasy, and the data architect community not so homogeneous if willing to consider as well data strategic governance, enterprise architecture viewpoint fully integrated in a comprehensive approach and PLM.

Analysis

For a set of common architect roles, we don't find exactly the same way for defining them.

In particular, FEAPO details competencies, ArchiMate viewpoints with concerns and SAFe the tasks/activities the architects are responsible for. As other methodologies, it also provides links to artifacts, and can provide RACI matrixes. ArchiMate and FEAPO descriptions are used methodology independant. They however allow capturing a detailed way the skills and concerns of considered architects. So they are quite interesting to consider.

Another way to understand these different roles/career profiles is to study the handbooks dedicated to these architects. It is something I made for Software architects and PLM architects dealing with Product Data Exchange, Sharing and Long Term Archiving.

In the article "What should we expect from software architects?", making the exercice allowed understanding better some differences with other architects. It also allowed understanding better some statements related to Agile Manifesto, the very weak usage of modeling, or the idea of emerging architecture which is strongly related to continuous code reengineering. Unlike this community, I'm convinced that model based approach brings a lot of value and is an enabler for agile at scale. But software architects need to be reconciled with modeling, and some other architect have to adapt their way of modelling, in a way they can communicate and collaborate more efficiently. It is the purpose of ArchiMate, and it is the reason why I'm promoting its usage as having to collaborate with many kind of architects and other disciplines.

Considering PLM standards and how to ensure PLM interoperability (Information, service and processes), which I addressed on many of my articles, we can see a sub category of architects which have a deep knowledge on manufacturing processes, system engineering and Information and Communication Technologies.

For this reason, I think that PLM remains an important enabler to consider in conjunction with modern data governance and technologies and with Enterprise Architecture. However, the way to achieve it will require a collaboration between the architects which could be difficult, because their communities and practices are disjoint. It is the topic I've been trying to address the last years, in particular through research activities and support of operational projects.

Conclusion

This article explores the different kinds of architect considered by enterprise architecture, being through a careers guide (FEAPO), an open enterprise modeling language (ArchiMate) or a methodology at the scale of the enterprises. Combining these different guides and specifications provides exploring in deep these roles and better understanding them. Analysing more in details Software architects handbook or practices of the Data Governance community, we can however discover that the viewpoint of each community is not holistic or complete, and that it is important for the architects having the respective knowledge of their respective communities to be able to work together, considering that they should combine their practices and their framework. A difficult challenge I've been exploring on my LinkedIn articles.

Don't hesitate to react (it can be easily improved), and eventually to like and share it if you think the provided analysis brings value.