enteprise architecture Archives

Data Driven Enterprise Architecture for Delivering Better Business Outcomes

Forget everything that you may have heard or read about enterprise architecture.

It does not have to take too long or cost too much. The problems are not with the concept of enterprise architecture, but with how it has been taught, applied and executed. All too often, enterprise architecture has been executed by IT groups for IT groups, and has involved the idea that everything in the current state has to be drawn and modeled before you can start to derive value. This approach has caused wasted effort, taken too long to show results, and provide insufficient added value to the organization.

In short, for many organizations, this has led to erosion in the perceived value of enterprise architecture. For others, it has led to the breakup of enterprise architecture groups, with separate management of the constituent parts– business architecture, information architecture, solutions architecture, technical architecture and in some cases, security architecture.

This has led to fragmentation of architecture, duplication, and potential sub-optimization of processes, systems and information. Taking a business outcome driven approach has led to renewed interest in the value enterprise architecture can bring.

But such interest will only remain if enterprise architecture groups remember that effective architecture is about enabling smarter decisions.

Enabling management to make those decisions more quickly, by having access to the right information, in the right format, at the right time.

Of course, focusing on future state first (desired business outcome), helps to reduce the scope of current state analysis and speed up the delivery of value. This increases perceived value, while reducing organizational resistance to architecture.

Understand their goals, objectives and pain points, and then help them to express them in clear business outcome related terms. This will take time and skill, as many business users simply asking for system changes without clearly stating their actual objectives.

Understand who the real stakeholders involved in and benefiting from the enterprise architecture are in your organization. While many stakeholders may still be within the IT organization, it is the business and C-level stakeholders who should be able to gain the most.

Review your current architecture efforts and tooling. Question whether you are providing or managing data the business does not need, whether you are working too deeply in areas that may not be adding value, or whether you have your vital architecture data spread across too many disconnected tools.

This blog post is an extract taken from Enterprise Architecture and Data Modeling – Practical steps to collect, connect and share your enterprise data for better business outcomes. Download the full ebook, for free, below.

Overcoming Teething Problems in Enterprise Architecture

Historically, the teething problems in enterprise architecture have prevented it from realising its full potential. However, the uptick in data-driven business has made the practice essential, meaning organizations are looking for an enterprise architecture approach that works best for them.

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 to avoid the historical problems in enterprise architecture initiatives and ensure it’s success going forward.

Problems in Enterprise Architecture: EA Needs Time

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 Architecture Enterprise 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.

Problems in Enterprise Architecture: EA Needs Attention

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.