Although they might not always be immediately obvious to the outsider, the value of Enterprise Architects to EAs and even many CIOs is clear. The practice has long been one of the best drivers of business transformation, and IT/business alignment.
Yet over the years, a number of studies indicate hurdles in the early stages of Enterprise Architecture maturity that can stop businesses progressing further with the scheme.
Take Gartner for example. In a 2007 survey from the world renowned tech analyst, Gartner found that 40% of Enterprise Architecture initiatives would be stopped. A later survey (2015) indicates at least a degree of accuracy in the former, as it showed 70% of businesses were looking to either start, or restart an Enterprise Architecture programme.
It seems as if, although businesses are aware of the advantages of an EA practice, actually introducing one can be difficult.
With that said, this blog will covers things to consider when implementing an EA practice, and ensure it’s success going forward.
Businesses that adopt EA on a whim – in that they know they should be doing in EA, but don’t fully understand why – will likely run into this issue.
We must understand that Enterprise Architecture is far from an overnight fix. In fact, it’s the polar opposite. Although EA might highlight areas where overnight and radical change could benefit a business, the initiative itself is a constant and gradual effort in working to align business and IT, aid in strategic planning, and improve processes.
As time goes on, the degree to which these efforts can positively affect the business will also increase, as the EA practice becomes more mature. The added capabilities of EA are indicated in Gartner’s maturity model shown below.
This is important for two reasons. Firstly, a maturing Enterprise Architecture practice implies business growth, and so more EA has to be done in order to cope, as there is more to manage.
Secondly, maturing in EA enables businesses to do a different kind of Enterprise Architecture. The typical, Foundational EA tasks – the one’s we refer to as keeping the lights on – will still be carried out. However, a more mature Enterprise Architecture practice can start using EA more aggressively, actioning what is known as Vanguard Enterprise ArchitectureEnterprise Architecture.
This kind of EA is more proactive, and it’s practitioners focus more on identifying opportunities and disruptions. This is the EA largely responsible for pushing business transformation and innovation, and so their results often have more lucrative, tangible results.
Most practices that abandon EA, do so without moving too far along the maturity model and so in most cases, are only doing entry level, Foundational Enterprise Architecture.
Much of EA consists of strategic planning. Thanks to the practice’s macrocosmic (top down) view of the organization, and business wide responsibility, the planning carried out by EA’s can affect the business as a whole. When dealing with change of this nature, what is implemented cannot be started and left to integrate on its own. This sort of radical change needs to be guided and supervised.
This is why if a business is going to take on EA, they need to think about the EAs wider role in the organization. Who should they report to, who should report to them etc.
Many people make the case that EAs should report directly to the CIO, and in fact, hold an advisory role to the CIO as well. Gartner analyst, Brian Burke echoes this sentiment, stating: “We’ve witnessed a change in mind-set, execution and delivery of EA. The value of EA is not in simply ‘doing EA’, but rather in how it can help evolve the business and enable senior executives to respond to business threats and opportunities.”
Therefore, just implementing the scheme isn’t enough. It needs aftercare. This is why EAs should work closely with CIOs, and the benefits of this come two-fold. On one side, the CIO gains a valuable asset in having an adviser with perhaps the most broad, top down view of the organization and its structure, in the business. On the other, the Enterprise Architect has a role more closely aligned with the top table, and can exercise more pull in decision making.
This relationship, and the extra attention to EA it provides could be the difference between success in EA, and an amassment of half started projects and eventual lapse in investment.