Keys to Enterprise Architecture Success

By Stuart Macgregor, CEO, Real IRM Solutions and The Open Group South Africa

Avoiding the perils on the way to successful Enterprise Architecture

Enterprise architecture (EA) is more relevant today than ever before – considering the accelerating pace of technology adoption, many new and disruptive market forces, hyper-competitive environments, and rapidly changing business models.

Together, these present a burning requirement for many organisations to ‘digitise the enterprise’.

EA supports the organisation develop an holistic representation of the business, its information and technology. This provides a business tool for managing complexity and change.

The myriad benefits from successful EA practices include:

• Competitive advantage – with so few organisations “getting it right”, having a business appropriate and sustainable EA function allows the organisation to respond to change with greater speed, and derive huge competitive advantage.
• Market reputation – EA is essential for the organisation to promote a reputation of being well-governed (for example, EA allows the organisation to comply with King III and other governance/compliance requirements). EA acts as the crucial linchpin between corporate governance and IT governance.
• Business transformation – EA supports major business transformations, by clearly understanding the current state, and clearly articulating the desired end-state. In this way, EA provides a clear roadmap for transformation
• Portfolio rationalization – a structured approach to EA helps with reducing the size and complexity of the organisation’s technology estate, and removing any duplications within the application and technology portfolio.
• Strategic support function – professional EA consulting services support the efforts of many critical areas within the enterprise – such as strategic planning, governance, risk and compliance, and solution architecture

In essence, EA facilitates the fusion between business and technology based on the fact that if the organisation cannot change its systems, it cannot change its business. New entrants are often more ‘digitally agile’: they have the ability – for example – to embrace new cloud platforms without being tied to millstone of legacy systems and processes.

The strategic theme that underpins the EA practice, and helps guard against failure, is that of ‘running the EA practice like a business, with a clearly-defined solution offering’.

Keeping this philosophy top-of-mind – across the entire ambit of people, tools, process, content, and products/services – is fundamental to ensuring that one’s EA practice is business-appropriate, sustainable, and ultimately successful. By running EA as if it is a business in its own right, in support of the enterprise’s strategic goals, the EA capability is positioned to evolve in scope and importance, and add increasing value to the enterprise over time.

However, so many EA programmes fail to achieve meaningful results. More often than not, they either end up on the scrapheap of failed IT programmes and wasted investments, or limp along with limited and isolated impact within the broader organisation.

So, why do EA programmes so often fail?

The role of the Chief Architect in ensuring EA success

Analysts confirm that the single biggest reason for failed EA programmes is lack of leadership skills within the core elements of the guiding coalition and the EA team. At the nucleus, the Chief Architect is required to lead by example and inspire others, while remaining acutely tuned into business’ needs.

Acting as the keystone in the EA structures that are being built, the Chief Architect must be flexible enough to continually adapt the business case for EA, but remain unwavering in the eventual vision – that of modernising and optimising the way the organisation functions.

The resilience of the EA function ultimately depends on the strengths of the Chief Architect.

As EA inevitably takes some time to generate sustainable returns, the Chief Architect must maintain the enthusiasm of executive stakeholders and business partners, while dealing with the ever-present threat that some individuals may revert back to old habits, divert funds to other projects, or focus on short-term wins.

This is a delicate balance, and the skills that qualify someone as a great architect don’t necessarily make them a strong leader. The most essential attributes include business acumen, the ability to translate technology into simple business outcomes, the ability to listen, communicate, present to groups, articulate the vision of the EA function, and inject enthusiasm for the EA practice.

Of course, it goes without saying that the Chief Architect must also possess the right technical skills which allow her to guide and govern the EA portfolio. In staffing the EA function, organisations should consider candidates in the context of defined career ladders and skills assessments. It is only with the right skills background that the Chief Architect will be in a position the strategic importance of the EA function within the first year of their tenure, or the practice is at risk of dissipating.

Leadership also includes aligning the differing EA visions held by the various business units and stakeholders. Everyone has a slightly different spin on what EA should achieve, and how the organisation will achieve it. While keeping stakeholders involved in the project, the Chief Architect must influence, guide, and delicately meld these visions into a single cohesive EA strategy.

Finally, the EA practice is at risk if the Chief Architect and her team are not skilled in communicating with key stakeholders across both business and technology domains and at multiple levels within the organisation. Results need to be clearly measured and demonstrated to the business. The EA vision must be constantly reinforced throughout the programme as the practice develops in maturity.

Setting up the EA team for success; the core EA team

As important as her role may be, the Chief Architect cannot ‘go it alone’. Ensuring that the right core Enterprise Architecture (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 organisation.

None of this can happen just by accident. 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 organisation, the Chief Architect is able to allocate resources efficiently and generate the best returns 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 that the EA practice becomes something of a ‘dumping ground’ for disparate IT team members. For this reason, when a new Chief Architect is appointed, one of her first tasks is to assess the team capabilities, 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.

Organisational positioning

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.

For example, if EA is housed within the area of the Chief Technology Officer then we can expect the focus to be all about technical architectures and solutions support. If it’s positioned under the Chief Information Officer, the focus is often more on supporting solution architectures.

Reporting into business strategy and governance structures reduces technology-centric thinking. Whichever is the case, we find that organisational structure shapes the behaviour and the strategies of the teams.

Appropriate structure and alignment within the organisation is critical for ‘expectation management’. We’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 organisation will build an integrated view of the target architecture. In highly federated, decentralised or geographically-dispersed organisations, 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.

The EA team needs to simultaneously build the EA capability (and start delivering results), while selling this positive story to executives – in order to achieve their further buy-in. This may place greater pressure on the teams in the short-term, as milestones and commitments are thrust into the spotlight and must be met. We recall the principle of ‘publish or perish’, which is crucial to maintaining the involvement and support of executive stakeholders.

Executive sponsorship

The business executive must empower the EA function with a defined and widely communicated mandate. Failure to do so often results in ‘turf wars’ between the EA practice and related areas of the organisation, such as the Programme Management Office or Service Management.

To build on early momentum, EA education and communication should filter down from above as one of the organisation’s highest priorities. This helps to foster business stakeholder engagement and ensure that EA content is used in the right ways “on the ground”.

Executives are also able to remove many of the obstacles that could otherwise bring on the demise of EA in the organisation. Executive sponsors may be called on to influence budgets and vendor selection, or make the necessary structural changes to the teams, or ensure that architecture governance remains firmly on the agenda.

So, in summary, it is critical to have the right people, under the right leadership (the Chief Architect and her guiding coalition), working in the right structure within the organisation. Without all three of these things in place, the EA practice is at great risk of failure.

Ivory Tower syndrome

A common reason for the collapse of EA initiatives, is architects who become overly-enamoured with the conceptual aspects of their work. They return from their retreats away from the business, with elaborate frameworks, and little practical guidance on how to implement them.

These concepts will be presented to key influencers within the organisation, most of whom will not understand the content, so their complex reference architectures will be ignored. In this way, the EA team is perceived as living in an Ivory Tower – disconnected from the business and alienating stakeholders – often leading to the withdrawal of support and sponsorship from key people.

These complex frameworks are built in isolation from the business stakeholders on the ground.

Investing too much time in detailed documentation of the “as-is states”, and creating vast arrays of diagrams, gives the impression that progress is being made, when in reality, this flurry of visible ‘activity’ is being mistaken for progress.

This academic approach to EA leads to inertia in decision-making, a state of ‘deferred commitment’ where the fear of failure leads to an inability to act. The EA practice lives by the principle of “publish or perish” (describing how critical it is to deliver tangible outputs).

This leads to distorted perspectives, where the architect’s views of the business architecture and other architecture domains are not necessarily shared by their key stakeholders.

Architects who dogmatically force their models on stakeholders – without fully appreciating the changing business’ requirements or tailoring their services to meet the business’ demands – are bound to fail.

By focusing on tangible outputs, and running the EA practice like a business, architects can effectively maintain a stakeholder-centric approach to delivering business value.

Architects need to ‘get their hands dirty’ – such as getting involved in the actual modelling, investing time in mentoring people in architecture skills, closely following the business’ needs, and evolving the EA artefacts.

This should be combined with strong marketing and communications efforts – where architects constantly communicate and evangelise the value of the EA practice to business stakeholders.

If not, the team risks the ‘Ivory Tower syndrome’ setting in, and will lose the backing of the C-suite. Even if budgets are still provided for, the bigger work surrounding EA – like maturing the EA capability, business transformation and change management – will not be possible without active executive support.

@theopengroup

Macgregor participated in the development of the Microsoft Enterprise Computing Roadmap in Seattle. He was then invited by John Zachman to Scottsdale, Arizona to present a paper on using the Zachman framework to implement ERP systems. In addition, Macgregor was selected as a member of both the SAP AG Global Customer Council for Knowledge Management, and of the panel that developed COBIT 3rd Edition Management Guidelines. He has also assisted a global Life Sciences manufacturer to define their IT Governance framework, a major financial institution to define their global, regional and local IT organizational designs and strategy. He was also selected as a core member of the team that developed the South African Breweries (SABMiller) plc global IT strategy.

Stuart, as the lead researcher, assisted the IT Governance Institute map CobiT 4.0 to TOGAF®. This mapping document was published by ISACA and The Open Group. He participated in the COBIT 5 development workshop held in London in 2010.