Decoding EA – The Role, The Title, and The Practice
In this article I would like to delve into the often-perplexing landscape of Enterprise Architecture (EA) focusing on clarifying the role, title, and practice of EA. There are myriad interpretations and implementations that contribute to the confusion surrounding this very important strategic planning function. From the commonly known responsibilities of EA professionals to the varying perceptions of their misnamed titles within organizations, I aim to shed some light on the complexity of this issue and provide suggestions to simplify the mysterious world of enterprise architecture.
Frequently posts appear on LinkedIn, especially within the architecture communities, demanding that architect roles, particularly the Enterprise Architect role, should be rebranded.
These posts claim, Enterprise Architects singlehandedly cannot build entire architecture for the enterprise that is detailed enough and ready for implementation. This is the true part of their claim. And therefore, they conclude with a broad statement that the Enterprise Architect role should be rebranded. The authors of such posts presume a person playing the Enterprise Architect role must be solely responsible for the design of entire enterprise in isolation without collaborating with other people within the organization. Clearly, there is huge misunderstanding about the nature of Enterprise Architect role.
Of course, people playing the Enterprise Architect role alone can never accomplish that feat all by themselves. In any IT organization, small or large, there are many architect roles of all stripes, who must collaborate with many people within business and IT during planning, creation, and implementation of detailed and holistic solution design for the enterprise. ?
See my article on architect roles (Its a Zoo of Architect Roles...).
To add to the confusion further, the abbreviated form “EA” can stand for many different things. I have seen it being used as a short form for Executive Assistant. But within IT this term has many meanings depending on the context. It represents Enterprise Architect as one of the standard architect roles; or it represents Enterprise Architect as a title given to a position within organization, regardless of whether or not the person actually performs any of the responsibilities that fall under the standard Enterprise Architect role.
EA is also used to refer to the architecture artifacts (blueprints or models) produced by the people playing the Enterprise Architect role. And finally, EA also represents Enterprise Architecture as a practice or discipline similarly to other established practices (e.g., Project management).
So, as you can see there is a big problem in the way the two terms “Enterprise Architect” and “Enterprise Architecture”, both abbreviated as EA, are used, and we all agree something must be done about this and urgently.
Clearly this is a very complicated issue. Unfortunately, this issue has gone unaddressed for too long, and the damage is already very palpable. It is virtually impossible to discern what is being expressed by people when they use these terms without understanding the complete context. ??
Oversimplification and trivialization of the issue purported by these LinkedIn posts within architecture communities create confusion inviting more questions than what they appear to answer.
Already there is a big confusion about the roles and titles, and the actual responsibilities assigned to people in IT organizations. See (The Problem with IT roles and Job Titles).
Unfortunately, the use of term EA during discussions between business and IT, and lack of common understanding of the Enterprise Architect role, title, and actual responsibilities of people playing the role is multiple of magnitudes more complex to handle.
This issue, of course, must be discussed and debated within the architecture community and within the IT community at large. However, the first thing we can do is to redefine various terminologies represented by “EA” and then agree to standardize their use in all discussions concerning EA as a standard role, as a position/job title, as architecture blueprints, or as capability/practice.
Here are a few suggestions to get the discussions started –
I am sure some of you have better ideas for what you would like to call these terms. But within the larger IT and architecture community we should all agree with one set of definitions and make use of them in all Standard’s frameworks (COBIT, ITSM, TOGAF, etc.).
Next, we should agree to what an architecture practice is in terms of well-defined standard set of services it provides to business and IT during strategic planning and execution cycles in support of meeting ultimate objective of providing the right products and services to the customers. ?
Every business is unique and will have unique needs for architecture services. So, for individual business, unique operating model for the architecture practice must be developed that seamlessly interacts with the rest of the business and IT organizations. Architecture practice alone is never enough to plan and deliver all strategic goals and objectives; as mentioned earlier, it takes many other business and IT capabilities for example, Business Planning, customer relations and marketing, UI/UX design, Organizational Change management, Traditional PMO or Agile product management, Business operations, Solution delivery, Security, Platform engineering, IT operations, etc.
Development of the IT and Architecture operating model for the organization should help identify various architecture skills required to provide needed architecture services. Then one can group together identified architecture skillsets under assignable architect roles.
领英推荐
Good news is that there are already three standard architect roles universally recognized and accepted under various IT management frameworks namely, Enterprise architect (EA), Solution architect (SA), and Technical/System architect (TA), so these need not be redefined or rebranded.
The names for these three standard architect roles are what they are due to their IT lineage. But most folks, especially in IT, have gotten accustomed to these names and understand the differences among these three roles and their responsibilities. It is however quite evident that more work is needed by the IT leaders in socializing these roles within larger business communities. ?
These roles require very distinct and special skillsets with level of expertise, although they do share some common skillsets as well. They all are equally important architecture roles when it comes to delivering holistic and detailed architecture for the enterprise covering both business and technology domains.
EA role has the enterprise-wide scope, depending on how one defines an enterprise; usually this role is associated with a product line or a line of business within the enterprise’s value chain. An EA role consists of business and technology skillsets to deliver holistic but conceptual level design of the enterprise to accomplish the stated strategic goals and objectives. The key consumers of conceptual design are the enterprise’s strategic planning leadership in both business and IT organizations.
SA has a solution scope within a given line of business. A SA role produces logical level design for a solution usually to be delivered within a program, project, or an epic scope. The SA role consists of relevant business and technology skills to design the given solution that aligns with the conceptual and reference architectures provided by the EA role. A SA role needs deeper skills in assembling correct solution building blocks consisting of real products, platforms, and services. The key consumers of the logical design are the program/project stakeholders within the business and IT.
TA has a component scope within the given solution designed by the SA role and being delivered under project stage/MVP release/sprint scope. Technical or physical design is highly detailed technical description of system / component that provides instructions to be implemented by the engineers. A TA role consists of relevant business and technology skills; however, people playing the TA role need very specific in-depth/hands-on technical skills in special technology stack for both frontend and backend solution building blocks being adopted within the solution design. The key consumers of the physical or technical architecture are the folks who are responsible for actual implementation, i.e., engineers.
As one can clearly see for any organization there is more need for people playing the SA role than EA, and more TA people than SA. These three roles operate in very different time cycles and speeds during end-to-end strategic planning and solution delivery process. EA operates in a much slower pace at strategic level, compared to SA. And SA much slower pace at program/project solution level than TA.
Finally, regarding the problem of proper role assignments, this is where appropriate design of the operating model is so important. As mentioned earlier, during every strategic cycle, leadership must continuously assess and improve the design of operating model for their respective organizations, especially this is very important for all IT organizations including architecture departments.
Based on the strategic needs, the IT organization’s target operating models and as a result, operating models for other core IT practices such as project management, IT change management, architecture, solution delivery, IT operations, security, platform engineering, etc. must be reviewed and revised to support the required new capabilities. The operating model informs design of IT org structure and as a result, right roles can be identified and assigned to the right people, by either reassignments internally or by hiring new people. ?
The changes to the IT organization (and role assignments) must be made such that they can support the technical capabilities needed for implementation of the planned strategic initiatives. Oftentimes IT positions, including architecture, are filled upfront just because additional headcount becomes available based on revised yearly budgets. This is clearly problematic since it does not factor in the true needs of the organization. ?
It is important to ensure all the changes in the IT operating model are approved and funded to ensure successful strategy execution. There are times when certain IT roles including architecture roles (EA, SA, and TA) are not necessary given the strategic imperatives, and so these roles must either be consolidated, reassigned, or even eliminated. Unfortunately, that’s the nature of IT and so however unruly and callous this may sound, a prudent governance must be applied. Organizations can mitigate this by balancing IT capacity by augmenting it with external temporary resources when needed.
In summary, the confusion stemming from unclear architecture roles and titles with misaligned responsibilities, is lot more complicated than people care to understand. The issue is very widespread within IT organizations in all industries and sectors. Architecture departments are not immune to this problem, in fact as discussed, the situation is even worse for architecture departments due to misunderstanding of various architect roles and responsibilities, meaningless titles, and confusing use of architecture terminologies.
Within IT organizations the architecture department is the most neglected place without clearly defined mandate and accountabilities. Only recourse for addressing this issue is for business and IT leadership to continuously monitor effectiveness of services offered by the architecture department and routinely review and revise its operating model to keep it finetuned so only the needed architect roles are stood up to effectively deliver the promised strategic solutions.
Author: Sunil Rananavare, IT Strategy Planning and Architecture (CIO Advisory)
Follow me on LinkedIn to stay informed. Share the article if you found the content useful.
?
The views in the article are author’s own and not necessarily of his employer.
?