enterprise architecture maturity Archives

Overcoming Teething Problems in Enterprise Architecture

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.

How To Kickstart an Enterprise Architecture Initiative

The increased rate in technology disruptions means more businesses than ever will be looking to start up an Enterprise Architecture (EA) initiative. This has extended to smaller businesses too – many of which wouldn’t have considered EA before – due to the availability of more accessible tools.

But where to start? Previously, looks into Enterprise Architecture tooling uncovered two alternatives. The legacy, established EA tools, high in productivity but equally high in cost and effort, and the drawing tools – such as Visio – that require excessive management and juggling of information between multiple applications.

First Steps in Enterprise Architecture

It’s important to establish what Enterprise Architecture is for, and why you would need to get started. Superficially, Enterprise Architecture is about the description and management of systems. In the past, it had been typified as a domain fit for “keeping the lights on” – the legacy attributes associated with IT. Today, largely due to the rise in digital business, the role of an Enterprise Architect has been pulled out of the shadows.

Now, Enterprise Architecture is more concerned with responding to disruption. EAs identify the potential for business and IT change, and analyze how best to execute or manage such changes to meet business objectives, desired outcomes and vision.

The Beginnings of Enterprise Architecture Maturity

Chances are, if you’re just starting out in EA, you’ll be ‘pre level 1’ on the maturity model. To take that first step into maturing the practice, and before you really start working on what your future state architecture looks like, you must understand your current state.

The frameworks to which your Enterprise Architecture will observe are also decided here. TOGAF, Zachman, DODAF are three common examples of such frameworks.

See also: Types of Enterprise Architecture Frameworks

Your choice will ultimately come down to what you’re trying to achieve with EA, the experience of your team, and whether you prefer a defined model.

To reach full maturity, your EA initiative will have to transition from ad-hoc, reactive EA, to something repeatable, and so a defined model best suits this long term aim. Typically speaking, the TOGAF method is most widely adopted.

That said, some organizations won’t want a standard method, and may start with a few object types and relationships. What matters most is that its understandable by the organization and that its repeatable.

At this point, you can move onto ‘Level 1’ maturity, carrying out ‘horizontal assessments’ of the business.

This is essentially ‘cleaning up’, sorting the data, resources etc., involved in the architecture of the enterprise, in order to build upon strong foundations going forward.

Any existing architectures should be united under one model, and one standard of terminology.

Disparity in this area can cause problems down the line, as it’s often common for different departments to have different names for the same thing and vice-versa, leading to duplicated or inaccurate data.

This is the point whereby existing data is imported into the EA repository. This should identify what the business has, and allow for modeling, roadmapping etc. going forward.

A best practice at this stage, is to start by creating a metamodel. Metamodels provide the top down, abstract view of the business and help EA’s establish alignment.

For example, they show the relationships between applications, and the business process they support, and a lack of such relationships and connections indicates areas of the architecture that aren’t properly aligned and non-functioning.

What Do I Need to Start An Enterprise Architecture Practice?

Most businesses start small, and mature the practice as they go, but some businesses with deeper resources opt to buy their way through Enterprise Architecture maturity – hiring consultants and acquiring a heavy-weight EA tool right off the bat.

For businesses where this isn’t an option, the usual process is as follows…

Typically, lower maturity EA set-ups feature a small team, an ad-hoc approach, and free and repurposed tools.

But as these EA practices grow, architects, stakeholders and business leaders often find that this approach can quite quickly become difficult to maintain.

Managing something as complex as an Enterprise’s applications, technology, information and processes across a suite of different tools that don’t interact with each other is hard enough as it is.

Then, when you factor in a growing team size, and add collaboration into the mix, this method can become nigh on impossible to sustain. sooner or later, an EA tool is required.

For more on deciding the best time to acquire a tool, click here.

How Much Do Enterprise Architecture Tools Cost?

Many companies think they can’t justify the costs, lengthy implementations projects and other resourcing factors. However, with the emergence of the Cloud and Software as a Service (SaaS) model, much of these initial headaches can be avoided. SaaS pricing models usually work on a “pay for what you need” basis, reducing the threat of a new tool purchase becoming shelfware. This makes them a great option for businesses who are looking to introduce an Enterprise Architecture programme for a specific initiative.

The SaaS model is also great for businesses that are looking to get off the ground quickly. The burden of having to pay for a consultant or technician to install the tool locally is relieved – saving both time and money.

We’ve seen a shift towards the model from leading tech providers recently. More and more enterprise tools are moving to the Cloud. One prime example is Google and their Apps for Work. Not only does the model save time and money, it can also greatly improve collaboration. Google’s suite demonstrates this, by allowing users to work together on a document or project remotely. Considering the nature of Enterprise Architecture – it’s top down view of the organization, and its inter-departmental linking of systems, people and other resources – this enabling of collaboration is vastly important to the industry.