Categories
erwin Expert Blog Enterprise Architecture

What Is An Enterprise Architecture Kanban Board?

Collaboration is vital to enterprise architecture, and one of the ways to facilitate collaboration is through an enterprise architecture Kanban board. It is an ideal way to manage and track work in progress.

Ultimately, the goal of an enterprise architecture initiative is to provide the organization with a complete view of the enterprise, its assets and functions.

A thorough approach to this requires input from the wider business and an enterprise architecture Kanban board can do just that.

A Brief History of Kanban Boards

Kanban boards are based on the concept of Kanban, a tool to visualize, organize and complete work.

In short, they are the visual storyboard for a process or workflow. They represent the journey and the concepts within that journey. Concepts are represented as cards on the board. Concepts may be moved from one stage to another by dragging a concept.

The first official use of Kanban can be traced back to Taiichi Ohno’s work at Toyota. He needed a way to quickly communicate to all workers how much work was being done, what state it was in, and how the work was progressing.

His goal was to make information and processes transparent to everybody and not just the management team – starting to see the relevance to enterprise architecture?

Kanban boards allow users to show the journey of concepts through your processes, improving visibility for the whole team.

Kanban Board Stages and Limits

A Kanban board is composed of stages. Stages are the placeholders for status of work and contain concepts. Depending upon the Kanban board that you are using, different types  of concepts may be present on a stage.

Each stage may be defined with a limit. A limit provides a maximum count for the number of concepts that can exist on a stage at any one time. This prevents a stage from being overloaded with too much work.

The use of stages also allows the Kanban process to be streamlined. The use of limits in various stages can force concepts along a pipeline and ensure that current work is complete before more work is added to a stage. Usually Kanban boards have administrators that may define the stages and limits on a Kanban.

Kanban Board Examples

Following are some examples of Kanban boards:

Innovation Management: Provides a journey through innovation management

Ideas Roadmap: Provides a roadmap by quarter of where ideas are likely to be released

Ideas Management: Provides a journey of the status of ideas on a simple task board

Requirements Management: Visualizes requirements over a development Kanban

Feature Management: Shows where a set of features are in the development process

Skills Management: Provides a view of what skills training is required to be planned

There is no dedicated “enterprise architecture Kanban board,” so they are completely customizable. Therefore, an “enterprise architecture Kanban board” describes a Kanban board used within the context of EA.

Agile Enterprise Architecture & Kanban Boards

Kanban derives from the just-in-time manufacturing methods that revolutionized manufacturing by focusing on what is needed to achieve a particular result and integrating the supply chain to maximize production.

In the agile enterprise architecture approach the production line is our contextual architecture for a particular change program or project and our supply chain in the myriad group of SMEs, partners, suppliers and the overall EA model.

It’s by connecting these parts that we can produce accurate, relevant, verified models to support the project teams that will implement the changes within the organization.

The agile EA approach places Kanban at the heart of managing the change context model and provides a clear focus on which elements of the architecture are needed in a particular context and provides direct connection to the wider stakeholders for collaboration.

When adopting an agile approach to EA, Kanbans provide a great way to move work forward at ease to achieve an end goal or objective. Kanban boards provide a “work- in- progress” view of EA concepts.

They provide an ideal way to track the visibility and status of our work in progress and provide a visual set of stages. Each stage contains a set of ‘cards’ that represent concepts.

Enterprise architecture kanban

For example, a card could be an idea, business capability or an application component. Each stage is identified by a name and a description of the stage. There are many different ways of defining a Kanban board. A typical board has the stages – Parked, To Do, Doing and Done.

However, most companies tailor the Kanban to suit their own environment and projects.

Kanban boards can also have visual indicators on the concepts (cards) such as colors to indicate status of different attributes.

In the example above, tags are shown as different colors on concepts, where they are tagged or categorized for an organization. This helps identify status of the cards on the Kanban and helps decide which we should focus on.

Agility and Collaboration

But as with enterprise architecture more broadly, the temptation to deploy make-shift Kanban boards for less mature enterprises is strong.

However, such approaches are unscalable, and will quickly have a detrimental effect on an organization’s scope to operate with agility and collaborate.

Organizations that recognize the need for greater agility and collaboration in their enterprise architecture initiatives must employ an enterprise architecture tool that facilitates such an approach, like erwin Evolve.

As well as the ability to create, manage and collaborate on Kanban boards, erwin Evolve provides these core capabilities to help EA programs succeed:

  • Flexible Configuration: On-premise or cloud-hosted with a customizable metamodel and adjustable user interface with user-defined views
  • Enterprise Models: Creation and visualization of complex models for strategy, processes, applications, technologies and data
  • Central Repository: Captures all relevant EA data, supporting thousands of users in central or decentralized environments with access from anywhere and automatic mass updates
  • Collaborative Web Platform: User friendly and business-centric to capture and edit data with surveys and other social features to promote communication between IT and business users
  • Reporting: Diagrams, dashboards, workflows and “what-if” analysis
  • Professional Services: Expertise to help maximize ROI, as well as provide custom develop

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

enterprise architecture innovation management

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

Agile Enterprise Architecture for DevOps Explained …

How do organizations innovate? Taking an idea from concept to delivery requires strategic planning and the ability to execute. In the case of software development, understanding agile enterprise architecture and its relevance to DevOps is also key.

DevOps, the fusion of software development and IT operations, stems from the agile development movement. In more practical terms, it integrates developers and operations teams to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.

The goal is to balance the competing needs of getting new products into production while maintaining 99.9-percent application uptime for customers in an agile manner. 

To understand this increase in complexity, we need to look at how new features and functions are applied to software delivery. The world of mobile apps, middleware and cloud deployment has reduced release cycles to days and weeks not months — with an emphasis on delivering incremental change.

Previously, a software release would occur every few months with a series of modules that were hopefully still relevant to the business goals.

The shorter, continuous-delivery lifecycle helps organizations:

  • Achieve shorter releases by incremental delivery and delivering faster innovation
  • Be more responsive to business needs by improved collaboration, better quality and more frequent releases
  • Manage the number of applications impacted by a business release by allowing local variants for a global business and continuous delivery within releases

The DevOps approach achieves this by providing an environment that:

  • Minimizes software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed
  • Replaces projects with release trains that minimize batch-waiting time to reduce lead times and waste
  • Shifts from central planning to decentralized execution with a pull philosophy, thus minimizing batch transaction cost to improve efficiency
  • Makes DevOps economically feasible through test virtualization, build automation and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value

An Approach with an Enterprise Architecture View

So far, we have only looked at the delivery aspects. So how does this approach integrate with an enterprise architecture view?

To understand this, we need to look more closely at the strategic planning lifecycle. The figure below shows how the strategic planning lifecycle supports an ‘ideas-to-delivery’ framework.

Agile Enterprise Architecture: The Strategic Planning Lifecycle

Figure 1: The strategic planning lifecycle

You can see the high-level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. Enterprise architecture provides the model to govern the delivery of projects in line with these goals.

However, we must ensure that any model built include ‘just-enough’ enterprise architecture to produce the right level of analysis for driving change. The agile enterprise architecture model, then, is then one that enables enough analysis to plan which projects should be undertaken and ensures full architectural governance for delivery. The last part of this is achieved by connecting to the tools used in the agile space.

Agile Enterprise Architecture: Detailed View of the Strategic Planning Lifecycle

Figure 2: Detailed view of the strategic planning lifecycle

The Agile Enterprise Architecture Lifecycle

An agile enterprise architecture has its own lifecycle with six stages.

Vision and strategy: Initially, the organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.

Value proposition: The ideas and requirements are rationalized into a value proposition that can be examined in more detail.

Resources: The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed.

Execution: With the strategy and transition plan in place, enterprise architecture execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and entered into or continue to the DevOps stage.

Guidelines: As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.

Updates: Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. If we’re not doing things the way we said we wanted them done, then we must ask if our target architectures are still correct. This helps keep the enterprise architecture current and useful.

Enterprise Architecture Tools for DevOps

DevOps can use a number of enterprise architecture solutions. For example, erwin’s enterprise architecture products use open standards to link to other products within the overall lifecycle. This approach integrates agile enterprise architecture with agile development, connecting project delivery with effective governance of the project lifecycle. Even if the software delivery process is agile, goals and associated business needs are linked and can be met.

To achieve this goal, a number of internal processes must be interoperable. This is a significant challenge, but one that can be met by building an internal center of excellence and finding a solution by starting small and building a working environment.

The erwin EA product line takes a rigorous approach to enterprise architecture to ensure that current and future states are published for a wider audience to consume. The erwin EA repository can be used as an enterprise continuum (in TOGAF terms).

Available as a cloud-based platform or on-premise, erwin EA solutions provide a quick and cost-effective path for launching a collaborative enterprise architecture program. With built-in support for such industry frameworks as ArchiMate® and TOGAF®,  erwin enables you to model the enterprise, capture the IT blueprint, generate roadmaps and provide meaningful insights to both technical and business stakeholders.

According to Gartner, enterprise architecture is becoming a “form of internal management consulting,” helping define and shape business and operating models, identify risks and opportunities, and then create technology roadmaps. Understanding how vision and strategy impacts enterprise architecture is important – with an overall goal of traceability from our ideas and initiatives all the way through delivery.

enterprise architecture devops

Categories
erwin Expert Blog

Agile Enterprise Architecture for Big Data

Big Data is a huge enabler for business. It provides business leaders and analysts with a depth of information and insight that had previously been impossible to understand.

But for many businesses, this depth isn’t always as inviting as one might hope and so the scope of big data, often becomes a catch 22. Big data’s greatest asset – namely, masses of information – can easily become it’s biggest challenge. Without proper direction, useful information in big data is actually more barren than its name suggests.

Yes, there is a lot of information there, but without the proper approach, sifting through the useful information can undo much of the productivity big data seeks to improve.

This is where Enterprise Architecture comes in …

Enterprise Architecture (EA) helps organizations identify and capitalize on new business opportunities uncovered by this new influx of information, by acting as the guiding rope for the strategic changes required to handle it. EA helps facilitate big data processing, and helps uncover and prioritize exactly which data can benefit the organization.

Enterprise Architecture has already changed a lot over the last decade or so, and architects are now expected to be far more business outcome orientated, and meet disruptions and opportunities head on, rather than acting primarily on optimization and standardization.

With big data, the role of Enterprise Architecture needs revising again. Too much happens too quickly for the old idea of Enterprise Architecture, one that involves carefully perfecting projects and pouring over detail, to still apply. Big data benefits from the “Just Enough” and “Just in Time” approach to EA, and that’s why …

Big Data requires an Agile approach

Big Data is a product of the mass information, digital business age, whereby opportunities are more plentiful, but have much smaller windows in which they can be capitalized upon.

The constantly changing landscape of modern business is directly reflected in big data and EAs will often have to react in real-time as the variables that dictate the data continue to evolve.

David Newman, research vice president at Gartner, spoke on this very topic. “For the EA practitioner, the balance shifts from a focus on optimization and standardization within the organization, to lightweight approaches,” he said.

“Big data disrupts traditional information architectures — from a focus on data warehousing (data storage and compression) toward data pooling (flows, links, and information shareability). In the age of big data, the task for the EA practitioner is clear: Design business outcomes that exploit big data opportunities inside and outside the organization.”

Therefore, just having an Enterprise Architecture initiative isn’t necessarily enough to properly leverage big data. EAs that are yet to focus on agility won’t find as much success as those that have.

One of the key best practices in transitioning to a more Agile EA initiative, and maintaining this Agility is heavily linked with the perception of EA itself. To truly be effective as an agile arm of the business that meets change and disruption head on, EA must step up from building business and IT architecture models to deliver business focused outcomes.

This is something that analysts and influencers all seem to agree on, as many have championed the business outcome approach to Enterprise Architecture now, for some time.

This shift from IT-system focus to business focus, arguably happened when the concept of a Vanguard Enterprise Architect was introduced, making a clear distinction between Foundational EA (responsible for ensuring “business as usual”) and the innovation focussed Vanguard EA.

In fact, Forrester even placed “assisting the business in opportunity recognition” at number one, in their list of ways enterprise architects lead their organization’s thinking.

One way in which Enterprise Architecture can seek to properly leverage big data to recognize new opportunities is by using a business capability map. Business capability maps can make it far easier to extract the relevant data, when the raw data itself is too large to effectively digest.

Enterprise Architecture can also indicate when an organization’s own data isn’t quite big enough. Often, organizations find themselves held back by inter-departmental walls and silos. Enterprise Architecture can help point out these areas where data sharing is lacking, and work on bridging the gap.

This makes the data provided in big data far more complete, and in turn, more useful in the decision making process.

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

Digital Transformation & Agile Enterprise Architecture

Digital transformation remains a hot topic as the convergence of new customer preferences and expectations, and the increasing number of touchpoints is driving business and technology decision-making like never before.

Rising to this challenge in the digital business world requires a laser-like focus on the customer and innovation opportunities, which means change is a necessity. Digital transformation is the crux to drive organizational, process and technology changes that help ensure the customer is more closely connected to, and better served by, the business.

Technology organizations will even begin to attribute their own revenue streams as digital business models play a much larger role in organizations of all sizes.

As such, enterprise architecture (EA) is extremely well positioned to support change and innovation initiatives, but how can EAs position themselves to influence and even lead digital transformation?

This will become increasingly relevant if analyst figures are anything to go by. IDC have forecasted that the percentage of enterprises creating advanced digital transformation initiatives will reach 50% by 2020, up from 22%. Additionally, Forrester sets out that only 27% of today’s businesses have a coherent digital strategy for how they will create customer value in the digital business world – a number which will only increase.

Digital Transformation Enterprise Architecture

Enterprise Architecture For Digital Transformation

Digital Transformation can be seen as customer and market pressures driving technology and organizational change and innovation that is necessary for the business to satisfy and delight its customer base (it is quite a mouthful I admit).

Architects should view the enterprise as a complex, living system and technology-enabled transformation requires a much more agile approach than traditional EA has been able to offer in the past. Focusing more on solving business problems than on extensive documentation, and taking a data-driven approach to transformation will allow EA to drive digital transformation.

Starting out on a transformation journey pursuing increased productivity alone is not going to deliver the kind of outcomes that will delight customers and set the foundations for competitiveness and growth. Instead, focus on the business opportunities that will allow you to better serve and delight the customer base, open up new products or services to the existing base, or open up a new customer segment entirely.

There is still much work to be done to break down the silos that exist; every department or line of business has its requirements and to a certain extent their own way of working, supported by applications that are siloed, resting on infrastructure silos.

In this type of environment the world is revolving around the organization’s infrastructure. But today, digital business often starts where the customer first touches the business online or via an app. This must be the new focus and the traditional silos need to be fixed in order to truly transform for the customer.

Transformation Requires Agile Enterprise Architecture

With as many articles and posts about digital transformation and EA, you’d think there was a defined clear path to follow on the journey to becoming a digitized business. Yet we all know there’s no recipe that can guarantee digital success.

One thing is for sure however, those organizations that can establish business agility as a strategic capability will be best placed to respond to the opportunities from digital transformation. An agile business means being responsive to new opportunities, resilient to risks, and innovative in the face of transformation requirements.

There are limitations to achieving business agility through EA, though. Those being:

  • EA is often buried deep within the IT team
  • EA has a poor connection to the business organization
  • EA is too focused on producing extensive documentation rather than delivering business outcomes
  • EA sits in an ivory tower

However, thinking about agility at the meta layer helps to describe an enterprise that is inherently agile, flexible and architected for continuing change and transformation. Start to think of business agility as a meta requirement, where requirement change must be supported. Even meta processes, where process change must be supported.

The agile EA needs to be oriented towards how things change, rather than the things themselves to help build an enterprise architecture and organization that can act with agility. Architects can focus on specifying technology that is inherently flexible so that it is capable of supporting the expected change.

EAs that can architect their organization for increased business agility can position themselves to influence and even lead digital transformation agenda, by providing the decision support system to focus and deliver on the right digital strategies.

enterprise architecture business process

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

Categories
erwin Expert Blog Enterprise Architecture

Enterprise Architecture Case Study: Collaborative & Agile Enterprise Architecture at Plymouth University

Plymouth University is the 15th largest University in the UK with over 27,000 students and almost 3,000 employees. It was recently ranked 37th in the Times Higher Education World University Rankings 2015 of institutions under 50 years old. A new erwin customer, Plymouth recently selected erwin’s agile enterprise architecture solution to support a collaborative approach to IT strategy planning and architecture decision-making.

Craig Douglas, Enterprise Architect at Plymouth University, spoke about their current initiatives and selecting a new tool. Craig leads the EA function, working with stakeholders across the organization to align corporate and IT strategies, and facilitate effective change for the University and its underlying processes, information and technology assets.

EA is a relatively new function at the university?

“Yes, EA is relatively new to Plymouth University and new to most of the Higher Education sector in the UK. It was introduced by the Head of Strategy and Architecture, Adrian Hollister, with the aim of creating a window into a sustainable IT future. This included governance frameworks, security, and documentation of the as-is and to-be. Adrian formed the Enterprise Architecture Practice of Excellence and invited people throughout the University to take part and have their say.”

What role does enterprise architecture play at Plymouth University?

“For us, it’s about taking the sound ideas of the business and looking at how we can best deliver them through technology. It’s no longer technology for technology’s sake, we’re focussed on adding value, improving efficiency, increasing performance, and making best use of existing capabilities to deliver what the business is asking for.”

What challenges do you face in EA today?

“We need to ensure we fully understand what we have in terms of technology and capabilities, and we need to constantly evolve on what we have and innovate. It’s important that we can understand where everything fits together with a complete view of all relationships and interdependencies. Once we have this, we can confidently produce diagrams and analysis to share our architecture honestly with the wider University and possibly beyond. It’s important to me to share our architecture with the widest group of stakeholders as possible.”

What prompted you to look for a new enterprise architecture solution?

“We’ve been running the enterprise architecture practice for about two years now and have a team of six architects. We had been using an open source EA tool but every week the management team would make requests and we would struggle to provide the answers they needed. So we began to look for a more collaborative platform that could help us produce all the required diagrams, reports and analytics with greater agility. We tried a few products and spoke with several different software vendors and ultimately opted for erwin.”

Why did you select erwin’s Agile Enterprise Architecture platform?

“erwin ticks all the boxes for being SaaS, multi-platform, collaborative, and flexible in that the underlying metamodel can be customized. It allows us to tailor our reporting capabilities and work with all stakeholders on architecture diagrams. Previously, I had to manually re-create a lot of diagrams produced by my colleagues which wasn’t ideal. Being able to work on a tablet is a real bonus too when it comes to mobility and sharing our architecture. Overall it ticked more boxes than the other tools and it’s very competitively priced.”

What’s next for enterprise architecture at Plymouth University?

“I’m excited about getting to grips with the platform and getting results from it. Overall we’ll be focussed on working much more collaboratively in enterprise architecture. We will be utilising the tool to push towards a complete understanding of our current capabilities and inform future projects like data centre, disaster recover options alongside many other high profiles opportunities. We’ll focus on using the diagrams and analytics to manipulate the metadata to get the end results.”

Visit the Plymouth University IT Strategy & Architecture blog for their latest updates.

enterprise architecture business process

Categories
Enterprise Architecture erwin Expert Blog

Agile Enterprise Architecture in Higher Education

Over the last 5-10 years enterprise architecture (EA) has gained momentum in the Higher Education (or Further Education) sector, with many University and College institutions establishing an EA practice to help get on top of constantly changing and complex IT strategy and business strategy requirements.

Universities are in an especially unique situation of being both a research business and education business, with a degree of overlap between the two (researchers are also often the educators). And the added dichotomy of Universities both competing and at the same time collaborating with each other.

There are many complexities to doing EA in Higher Education, with tightening budgets, pressure to rationalize IT and related support and services. At the same time they must provide flexibility to cope with changing requirements, deliver innovative services to students and academics, and prepare for whatever is next on the horizon.

This is where agile enterprise architecture helps. But first, let’s briefly look at the current state of EA in Higher Education.

Agile enterprise architecture for universities

Enterprise Architecture in Universities

There are varying levels of EA maturity in the University/College ecosystem. Less mature organizations will often utilize Visio, Powerpoint or UML modelling tools to complete architecture-related tasks. However, there are major challenges with these tools around consistency of multiple diagrams, the effective communication and collaboration of architecture assets with stakeholders, and the timeliness of assets for use in decision making.

At the opposite end, the more mature institutions have purchased specialist tools and established an EA practice, and are using a common EA language such as ArchiMate® to build, manage and communicate assets in a consistent manner.

So what’s next for Higher Education institutions?

Adopting Agile Enterprise Architecture in Education Institutions

Every year EDUCAUSE, the non-profit organization whose mission is to advance higher education through the use of IT, publish a list of Top 10 IT Issues. One major theme from the 2015 list is the shift in Higher Education IT’s focus from technical problems to business problems, along with the growing interdependence between the IT organization and business units.

How Higher Education institutions respond to this acceleration of changing IT and business requirements is a top issue for Enterprise Architecture. To simply keep pace with the rate of change in 2015 and beyond, organizations must develop the capability to act with agility, to learn, respond and take action in shorter amounts of time.

What’s required is a new approach to enterprise architecture that’s focused on producing just the right amount of architecture assets for senior stakeholders and decision makers – communicating architecture quickly and only when it is valuable to do so for more agile IT and business decision making.

In the past, architects have often been guilty of producing detailed EA documentation but much of it providing little value to senior decision makers. Universities need to move away from this and adopt an agile enterprise architecture approach.

enterprise architecture business process