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