Take one for the team

In my previous Industry Insight, I explained how the central figure in the enterprise architecture (EA) practice - and the most pivotal role-player - is the chief architect. But, as important as this role may be, the chief architect cannot 'go it alone'.

Ensuring the optimal core EA team is in place is the next important step in avoiding potential EA failure. Led by a strong guiding coalition and steering committee, the team needs to consider how to manage the work, how to control delivery against the plan, how any blind-spots will be identified, and how they will engage with the rest of the company.

Doing this requires careful planning and managing. The starting point is to conduct a critical analysis of the skills requirements, and match this with the right people in the right roles. Any silos or 'stovepipes' should be dismantled, in favour of greater collaboration and knowledge-sharing - giving the chief architect better visibility of everything happening within the team.

So, with a strong EA team at the nucleus, and skilled individuals in the various areas of the business, the chief architect is able to allocate resources efficiently and generate business value in the least possible time. Excellence in the execution of the EA tasks, from beginning to end, is only ever possible with quality staff involved.

There is an ever-present risk that the core team gets pulled into detailed operational work like solution delivery - while the strategic architectural role gets deprioritised. Another common risk is the EA practice becomes something of a 'dumping ground' for disparate IT team members. For this reason, when a new chief architect is appointed, his/her first tasks are to assess the team capabilities and experience, address competency gaps, upskill individuals, restructure, replace and recruit where necessary.

The goal is to ensure the right portfolio of skills is spread across the entire EA discipline - people with the right qualifications, tool proficiencies and psychometric profiles are working together in the optimal structure.

As the team is being moulded to suit the organisation's needs, successful chief architects often leverage the capabilities of specialist consulting houses. They can be easily on-boarded in the short term, and help to stimulate the immediate revitalisation of the EA practice. It is an approach that helps the chief architect to "buy some time" to address the strategic and stakeholder relationship aspects of the role.

With many failed EA projects, the origins of many problems can often be traced back to the placement of the EA function within the company's design.

If the chief architect and his/her team report to the chief technology officer, one tends to find an unbalanced focus on purely technical architectures and solutions support. If the EA portfolio is housed within the ambit of the chief information officer, the focus is often more on supporting solution architectures.

Whichever the case, organisational structure shapes the behaviour and the strategies of the teams.

Excellence in the execution of the EA tasks is only ever possible with quality staff involved.

To have legitimacy among executive stakeholders, and to avoid knee-jerk, short-term approaches that merely address symptoms (rather than dealing with root causes), the appropriate placement of the EA function is fundamental to its success.

Appropriate structure and alignment within the company is also critical for 'expectation management'. I've seen many cases of senior stakeholders (within whose portfolio the EA function resides) making promises to executives, shareholders, or markets - creating unrealistic expectations of what EA is capable of doing at a particular level of maturity.

The organisational design must be fit-for-purpose, depending on the firm's specific requirements and the state of maturity. The EA function will be hindered if its scope is not clearly defined, and does not span all of the horizontal EA domains (business architecture, information architecture, data architecture, application architecture and technology architecture) and vertical domains (integration, security and solution architecture).

If these areas are fragmented, it becomes tougher to answer questions around how they will integrate, who will be responsible for what, and how the company will build a single view of the target architecture. In highly federated, decentralised or geographically dispersed companies, the positioning becomes even more complex - often being required to morph according to changing business priorities. This requires a clear understanding of what EA capabilities are performed globally, regionally and locally.

In my next Industry Insight, I will look at how the EA team should guard against becoming overly conceptual in its approach - a state I refer to as 'Ivory Towers'.