Tag: just enough

Categories
Enterprise Architecture erwin Expert Blog

What Is Agile Enterprise Architecture?

Having an agile enterprise architecture (EA) is the difference between whether an organization flourishes or flounders in an increasingly changing business climate.

Over the years, EA has gotten a bad reputation for not providing business value. However, enterprise architecture frameworks and languages like TOGAF and ArchiMate aren’t responsible for this perception. In fact, these standards provide a mechanism for communication and delivery, but the way enterprise architects historically have used them has caused issues.

Today, organizations need to embrace enterprise architecture – and enterprise architecture tools – because of the value it does provide. How else can they respond to business and IT needs or manage change without first documenting what they have, want and need?

Because that’s exactly what EA addresses. It provides business and IT alignment by mapping applications, technologies and data to the value streams and business functions they support.

Essentially, it’s a holistic, top-down view of an organization and its assets that can be used to better inform strategic planning.

But what is an agile enterprise architecture, and what are its advantages?

The Need for Agile Enterprise Architecture

The old adage that anything of any complexity needs to be modeled before it can be changed definitely holds true.

The issue is that enterprise architects tend to model everything down to an excruciating level of detail, often getting lost in the weeds and rarely surfacing for air to see what the rest of the business is doing and realizing what it needs.

This often makes communicating an organization’s enterprise architecture more difficult, adding to the perception of enterprise architects working in an ivory tower.

Just-in-Time vs Just-Enough Enterprise Architecture

Just in time, just enough and agile development and delivery are phrases we’ve all heard. But how do they pertain to EA?

Just-in-time enterprise architecture

Agile is based on the concept of “just in time.” You can see this in many of the agile practices, especially in DevOps. User stories are created when they are needed and not before, and releases happen when there is appropriate value in releasing, not before and not after. Additionally, each iteration has a commitment that is met on time by the EA team.

Just-enough enterprise architecture

EA is missing the answer to the question of “what exactly is getting delivered?” This is where we introduce the phrase “just enough, just in time” because stakeholders don’t just simply want it in time, they also want just enough of it — regardless of what it is.

This is especially important when communicating with non-EA professionals. In the past, enterprise architects have focused on delivering all of the EA assets to stakeholders and demonstrating the technical wizardry required to build the actual architecture.

Agile Enterprise Architecture Best Practices and Techniques

The following techniques and methods can help you provide just-enough EA:

Campaigns

Create a marketing-style campaign to focus on EA initiatives, gathering and describing only what is required to satisfy the goal of the campaign.

Models

At the start of the project, it doesn’t make sense to build a fancy EA that is going to change anyway. Teams should strive to build just enough architecture to support the campaigns in the pipeline.

Collaboration

Agile teams certainly have high levels of collaboration, and that’s because that level is just enough to help them be successful.

In light of the global pandemic, such collaboration might be more difficult to achieve. But organizations can take advantage of collaborative enterprise architecture tools that support remote working.

Planning

In iteration planning, we don’t look at things outside the iteration. We do just enough planning to make sure we can accomplish our goal for the iteration. Work packages and tasks play a large role in both planning and collaboration.

Agile Enterprise Architecture to Keep Pace with Change

As one of the top job roles in 2020, it’s clear organizations recognize the need for enterprise architects in keeping pace with change.

In modern business, what’s also clear is that maximizing the role’s potential requires an agile approach, or else organizations could fall into the same ivory-tower trappings burdening the discipline in the past.

Organizations can use erwin Evolve to tame complexity, manage change and increase operational efficiency. Its many benefits include:

  • Agility & Efficiency: Achieve faster time to actionable insights and value with integrated views across initiatives to understand and focus on business outcomes.
  • Lower Risks & Costs: Improve performance and profitability with harmonized, optimized and visible processes to enhance training and lower IT costs.
  • Creation & Visualization of Complex Models: Harmonize EA/BP modelling capabilities for greater visibility, control and intelligence in managing any use case.
  • Powerful Analysis: Quickly and easily explore model elements, links and dependencies, plus identify and understand the impact of changes.
  • Documentation & Knowledge Retention: Capture, document and publish information for key business functions to increase employee education and awareness and maintain institutional knowledge, including standard operating procedures.
  • Democratization & Decision-Making: Break down organizational silos and facilitate enterprise collaboration among those both in IT and business roles for more informed decisions that drive successful outcomes.

You can try erwin Evolve for yourself and keep any content you produce should you decide to buy.

Collaborative enterprise architecture

Categories
erwin Expert Blog Enterprise Architecture

Why Enterprise Architecture Agility is Becoming Increasingly Important

The importance of enterprise architecture agility is growing at a rapid pace.

Technology has made us faster. In the last century, we’ve found ways to travel faster, exchange information faster, and most importantly – innovate faster. In fact, there’s an argument to be made that perhaps we’ve entered an age where we innovate too quickly.

Think about it – how can any company aim for longevity when the next industry revolutionizing innovation is just around the corner. And it seems as if there’s a new one every other month.

Start-ups like Uber, Deliveroo and others have already reshaped their respective industries and largely without much – if any at all – forewarning. These disruptions to the market can rarely be planned for. Much of this is down to the nature of the internet and how quickly a message can spread.

Now that more and more products are being offered in the form of software, and within that, more and more of those being SaaS offerings, it’s not hard to imagine yet another uptick in the speed in which the market changes and evolves.

This is a particularly important area of focus for Enterprise Architects, as they are largely going to be responsible for implementing and integrating these new technologies. And with the evolution of Enterprise Architecture itself, from fringe support IT role to a forward thinking source of innovation, EA’s will even be responsible for sourcing new tech, predicting market trends, and generally operating with the businesses future-state in mind, in order to stay ahead of the curve.

So how do you account for rapid and unforeseen changes in strategic planning?

Well, the short answer is that you don’t. Realistically, you can’t plan for something if you don’t know…

  1. What’s coming
  2. When it’s coming

Businesses must instead prepare to react. This is what’s at the core of “being agile”, – a business mantra and way of operating that has been championed by many of the leading analysts, including Gartner, Forrester and others for a number of years now.

The point in being agile is understanding that you’re not always going to be ahead of the curve. This is because it’s impossible to constantly live “outside the box”. Eventually, an outside of the box idea becomes the box, and it takes a new outsider to really pivot the market.

Agility then, is about making sure that when disruptions occur, you’re not only ready to change course (or in some extreme cases, radically pivot), you’re also ready to turn disruption into opportunity.

What does agility mean to Enterprise Architecture?

In Enterprise Architecture, agility is mainly about reducing time to markets and making the practice more efficient.

There are a number of ways in which this can be achieved. Some relate to how EA is done, and some relate to how EA is perceived by the wider business.

Firstly, when it comes to doing EA, one best practice is the “just enough” mantra. Just enough Enterprise Architecture aims to avoid the issues that can plague an EA initiative due to over analysis.

Enterprise Architecture is one of those disciplines where it could be argued that the work is never done – but that doesn’t mean that there isn’t a time to stop and move on. Instead of documenting every inch and detail of an organization, EAs should instead aim to to deliver just enough to support the desired business outcomes.

A failure to implement just enough Enterprise Architecture plays a huge part in an organization’s failings in staying agile. It takes the EAs focus away from the businesses future-state, and instead, bogs them down with the past and current.

Of course, it’s vital for an EA to understand a business’s current capabilities, but looking forward is a huge part of the balance that makes a successful Enterprise Architecture effort.

If you feel your Enterprise Architecture efforts get bogged down with “analysis paralysis,” you should try using a goal based decision process. This keeps a focus on what needs to be built and by when.

Another reason an Enterprise Architecture department might be struggling to increase agility is the lack of a purpose built EA tool. As Enterprise Architecture has traditionally been quite expensive to get off the ground – with installation, upkeep and other costs – many businesses have resorted to using a hodgepodge of not-for-purpose Office Tools.

It’s a viable option at first, but as the Enterprise Architecture grows, these guerrilla Enterprise Architecture efforts often become increasingly difficult to manage as the architecture’s documentation spills across multiple files that can be exclusive to multiple people.

A purpose built EA tool with a strong focus on collaboration means that Enterprise Architects can share and collaborate on work directly within the tool. It also makes the architecture as a whole far easier to navigate and present to the wider business as it’s all kept within the same programme.

The improved capabilities in collaboration can also help with EA’s perception in the wider business. Getting stakeholders more involved in the EA makes its purpose and value far more clear.

This will lead to an environment where EA and the results it produces are treated with more dignity and trust, aiding in increasing agility by removing some of the bureaucratic hurdles faced before.

It’s now easier than ever to kickstart an Enterprise Architecture initiative with an EA tool. SaaS offerings with staggered license types especially, can be an in for businesses starting at Level 0 on the EA maturity model. Businesses no longer need to worry about the massive up front cost, and with the option to buy more licenses, the tool can scale with the EA initiative as it develops.

enterprise architecture business process

Categories
Enterprise Architecture erwin Expert Blog

Just Enough Enterprise Architecture, Just In Time: 5 Best Practices to Achieve Peak Enterprise Architecture Agility

The concept of ‘agility’ has permeated almost every inch of the enterprise. It’s not hard to see why either. The promise of faster time to markets, better management of change and disruption, and leaner, more efficient operations is clearly an appealing.

Enterprise Architecture (EA) is no exception to the rule. It might have been, for a time – when EA only really concerned itself with ‘keeping the lights on’. But now that the domain has found itself aligned more closely to the center of the business EA has to be concerned with agility too.

Some Enterprise Architecture practices can struggle to really achieve agility because of various reasons. We’ve put together 5 best practices to help architecture teams deliver greater business agility and also become more agile in their own approach to EA.

Just Enough Enterprise Architecture, Just in Time

One of the most common barriers to agililty is doing too much. The complex nature of Enterprise Architecture can lead to some architects building many rabbit holes where too much unnecessary information is captured and modeled that work is never ‘done’. This state is known as ‘analysis paralysis,’ as it effectively slows down the process and time to market of EA business-outcomes. Architects should stay focused on delivering Just Enough EA to support business outcomes, instead of documenting every last detail of the organization.

Of course there are times when very deep EA is required, but as a general rule it is better to focus on Just Enough Enterprise Architecture. Whether through curiosity to learn more, or paranoia that something will be missed, attempting to model and analyze everything is fundamentally at odds with agility.

To help focus on Just Enough EA and avoid getting lost in the detail, architects should:

  • Separate Enterprise Architecture from Solution Architecture, understand that detail does exist where Architecture meets design
  • Use a goal based decision process, keeps a focus on what needs to be built and by when
  • Concentrate upon interfaces / relationships
  • Define the core properties to be collected and implement quality checks
  • Harvest and connect to records of source

A lean and agile approach to Enterprise Architecture allows architects and non-architects alike to access the information they need much faster too, since EA modeling and content is no longer weighed down by a lot of unneccessary detail. EA is more likely to secure investment this way, too – as stakeholders are more likely to invest when the business outcomes can be translated more clearly and quickly.

Engage and Collaborate with Business Stakeholders

Another hurdle to EA agility is approval. Architects often reach a point where they can’t continue without the approval and buy-in from business leaders. The quicker you can get your stakeholders on board, the faster you can move through the strategic planning process into execution. This efficiency is essential to the agile mantra.

The ivory tower perception of Enterprise Architecture that has traditionally plagued the discipline makes this even more of an issue. Stakeholders are more likely to be reluctant to invest (be it time, money or resources), if the business outcomes aren’t completely clear.

One way to solve this is to help stakeholders get a better understanding and view of enterprise architecture. Getting them engaged and collaborating on the applications, processes or business capabilities they are interest in via an easy-to-use EA tool is ideal. We can also borrow ideas from Just Enough Enterprise Architecture (mentioned above). Your stakeholders shouldn’t have to learn how to do Enterprise Architecture in order to provide input and see its benefits.

Organizations with a collaboratively driven tool can provide stakeholders direct links to specific assets in the architecture. This negates any learning curve stakeholders might have needed to navigate the tool itself, gets them straight to their point of interest, and saves them time.

Enterprise Architecture collaboration

Giving stakeholders the ability to view and contribute directly within the EA tool itself, negates the need to go back and forth with static diagrams and reports. Instead of printing out PDFs and the like (which is actually just sharing), EAs can collaborate with stakeholders in realtime allowing them to see the impact of different changes on the business and to guide investment decisions.

Ensure Your Content is Stakeholder Focused

Although it’s best to engage and collaborate with stakeholders in EA, in some cases, the stakeholders can only really take a passive role. In this case, making sure what you present to the stakeholder is tailored to them, is another great way of removing stakeholder concerns as a hurdle to agility.

View managers are a great quality of life data management system, that can help EAs achieve this. They’re already commonplace in many Business Intelligence tools and CRM Systems, but can be just as useful in EA.

The purpose of a view manager is to streamline both the visulaization and navigation of data. They take a set of user defined parameters, and act as a filter to show only what’s relevant to that view.

View Manager explained

Much of this ties into the concept of showing ‘just enough’ EA and can help users and the wider business stay agile by trimming the irrelevant data that can slow down decision making.

View Managers could also be used as a tool specifically purposed to improve agility and efficiency across the business. For example, a view could be created to always display all business capabilities or perhaps all applications that you own. It could then be sorted to show the most critical capabilities – based on their importance to the business – first.

This helps provide architects with a clear view of their own priorities but similarly which organizational priorities should be tackled first.

A business capabiltiy view is just one possible example. In terms of agility, the view would help improve the efficieny at every stage in strategics planning process, increasing agility and time to market across the board by improving systems and processes.

Kanbans

Kanban Boards are a common form of task management in business. In short, they operate as a visual representation of the current state of a specific task(s). The typical parameters are “to do”, “doing”, “done” and “parked”, but many businesses choose to define their own parameters to better suit their needs. For example, a Kanban board that follows the different stages of the TOGAF ADM.

In relation to agility, Kanbans are a great way of organizing and prioritizing your own and your teams activities. This structure is the basis for any credible attempt at a truly agile operation. Without it, organizations often find themselves wasting more time deciding what should be done, that actually doing.

Kanban’s are versatile enough to be used at almost any point in the strategic planning process – including Enterprise Architecture. In EA specifically, Kanban boards could include cards representing business capabilities, or application components, providing a work in progress view of the architecture.

Get the Right Tool

Most organizations start small with EA, repurposing tools such as Powerpoint, Excel and Visio.

This budget approach to managing EA can most definitely get you off the ground. But as the architecture grows, the silos created when fragmenting the architecture across multiple programs and file types stifle progression.

It becomes difficult to work collaboratively, as multiple team members struggle to keep aligned. In many cases, there will be multiple different versions of the architecture that don’t fully corroborate with one another.

The most direct impact on agility though, is the fragmented state of information and assets. The dispersed nature of the data makes it extremely hard to find the information you need, making the EAs day-to-day job harder, as well as introducing further complications when presenting the architecture to stakeholders. EA can be complicated enough for the experts, let alone the stakeholders that are only involved sporadically. These are complications it can do without.

The right tool would be one that unifies the Enterprise Architecture, as well as the architects – allowing them to work collaboratively within one tool, with real time feedback and comment systems across the diagrams, roadmaps, pivot tables, impact analysis and capability models.

collaborative enterprise architecture

Categories
Enterprise Architecture erwin Expert Blog

Avoiding Analysis Paralysis With “Just Enough” Enterprise Architecture

In the past, analysis paralysis and enterprise architecture had gone hand in hand causing bottlenecks in new initiatives.

It’s natural that you want to be accurate and your work correct. But it’s very easy to become so focused on having every last detail 100% perfect, that it results in delayed decisions and business outcomes – or, “Analysis Paralysis”.

In this article we lay out actions that you can follow to help avoid analysis paralysis pitfalls using “just enough” enterprise architecture, and look at the tools and techniques available to build, analyze and communicate it effectively. First off, here’s a definition I think explains the concept quite well:

“Analysis paralysis or paralysis by analysis is an anti-pattern, the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome.”

Set a decision deadline

In today’s business environment, the actions (or inactions) of an individual have an impact on those above, below and beside them. Determine the timeframe in which your analysis or recommendation MUST be completed to avoid a stalemate situation where others are waiting on you.

Enterprise Architecture specifics:

  • Set distinct timescales when defining architecture change
  • Set change around Time based, Goal Driven initiatives

Often organizations have long timescales for analysis and get embroiled in building complex models when what is really needed is to understand the objectives and key initiatives in the business. Once these are clearly understood then change campaigns can be designed to deliver an architecture that fits the business.

Ask colleagues/peers for a sanity check

Including others in your work process improves the likelihood of an effective outcome. Diversity of thought gives you a broader context by which to build, analyze and communicate information.

Enterprise Architecture specifics:

  • Incorporate ideation
  • Understand the key players and ask for them to collaborate directly in the process
  • Avoid building a model in isolation and then asking for comments and suggestion

Look to incorporate multiple stakeholders either directly or by using output from any IT innovation campaigns that exist within the business.

IT Innovation Campaign

Collaboration is about asking people to help directly in the architecture process. This is key to not over analyzing the model, but focus on what needs to be done. An example would be to collaborate directly with the security team should a model component have a security impact.

Don’t get lost in information/Don’t get lost in the detail

It can be easy to lose oneself in a rabbit hole of information. Whether that be out of an innate curiosity to learn, or a paranoia that there is significant, and increasingly important information just a little deeper.

It’s undoubtedly a tough cycle to crack. Yet it’s solution unfortunately draws a line between frustration and simplicity. That’s because, simply put, the answer is just strict self control and regulation. Limits should be set and adhered to, so that you can efficiently establish what you’re trying to understand in the present, and what you’d like to accomplish in the future.

Enterprise Architecture specifics:

  • Separate Enterprise Architecture from Solution Architecture, understand that detail does exist where Architecture meets design
  • Use a goal based decision process, keeps a focus on what needs to be built and by when
  • Concentrate upon interfaces / relationships
  • Define the core properties to be collected and implement quality checks
  • Harvest and connect to records of source

Avoid detail by focusing on how to make strategic changes rather than a focus on how a solution is going to be built. Thus, we should pay more attention to delivering capabilities, and not the configuration of solutions. This means we need to model by capability and look for high level architecture patterns.

Don’t wait for optimal decisions

Waiting on optimal decisions carries many of the same problems as getting lost in information. Whether or not a decision is optimal is completely subjective to circumstance.

Meaning that if you do wait, and the opportunity passes, you’re then waiting for the next horizon of peak opportunity, looking out for similar signs as before as to point it out. However, as you’ve waited, the likelihood is that the circumstances would have changed around you, meaning that those same indicators will no longer be relevant.

This creates a perpetual cycle of waiting – waiting… waiting. A better approach is to make decisions in optimal ‘moments’, quelling the stagnation of perpetual waiting. After all, decisions can be tweaked and changed in the future, it’s indecision that stays the same.

Enterprise Architecture specifics:

  • Use analytics and cost analysis driven by focus on desired outcome
  • Focus on goal based analysis
  • Just enough architecture to support an optimal decision at a point in time
  • Adopting a more agile approach to enterprise architecture, in order to adapt decisions in the future when required

Make optimal decisions based upon SMART objectives, focus on building the architecture to deliver the capability at a point in time. This is what is at the hub of just enough architecture.

Goals and capabilities should be broken down into components and we should focus on delivering an architecture to support them. A series of small iterations, whilst collaborating with the key people will build an actionable architecture. Use Kanban to manage the process, roadmaps to validate a particular solution against the required capabilities and goals.

Step towards a decision

One of the reasons people find making decisions so difficult, is the weight of the decision in question. For example, the decision to perform a 180° turn on a plan you’re currently actioning might seem infeasible. 18, incremental, 10° shifts? Not so much. Smaller decisions and the smaller shifts in action that they carry are a great way of wriggling out of analysis paralysis.

Enterprise Architecture specifics:

  • Understand the iterations required to build a solution
  • Kanban the iterations
  • Use impact analysis to reveal dependencies
  • Roadmap by goal and capability

Use all the tools available – Kanban to manage the process including collaboration, use diagram tools to see architectural dependencies, roadmap goals, capabilities, applications and infrastructure.

If we keep the models at a high level answering goal based questions then we can build just enough architecture.

Summary

The core purpose of Enterprise Architecture can be outlined as follows:

  • Aligning IT investments with business needs to increase their profitability
  • Highlighting weaker, less cost efficient areas of a business and amending them
  • Improve the decision making at executive level
  • Increasing the benefits from innovation
  • Delivering strategic change initiatives

(Source : Gartner)

What do we find? Complexity in presentation of data; detailed design models instead of stakeholder based outputs; and the mixing of Solution Architecture and Enterprise Architecture. Additionally, it can be impossible to make decisions unless you abstract upwards.

Doing just enough is a case of focusing on outcomes and not building detail. It means focusing on goals and how to address them. Incorporating existing Innovation initiatives.

Creating Capability based models to represent the business. Associating with Application and Technology layers to understand solution patterns rather than the exact solutions need to make key decisions.

Choosing to focus on just enough architecture that focuses on high value business outcomes, gives the architect the best chance to deliver the core purposes of EA. All this adds up to increasing time to market, and quite simply – less headaches.

enterprise architecture business process