Tag: enterprise architecture

Categories
erwin Expert Blog Enterprise Architecture

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
erwin Expert Blog Enterprise Architecture

How Enterprise Architecture Underpins Strategic Planning

Strategic planning enterprise architecture is helping organization’s keep their enterprise architecture initiatives business outcome focussed …

Strategy essentially describes an organization’s means to an end. Good strategy requires a healthy understanding of the end goal before the methods to reach it are hashed out, and much of this understanding lends itself to “Strategic Planning.”

In short, strategic planning refers to the defining of strategy, goals and direction, but it also expands to the allocation of the resources needed to meet said targets.

So where does Enterprise Architecture come in?

In defining Enterprise Architecture (EA), leading business analysts, Gartner, have this to say: “Enterprise Architecture is a strategic planning process that translates an enterprise’s business vision and strategy into effective enterprise change.

EA teams work with stakeholders in IT and the business at large to define a future-state vision of the company. They consider future requirements, principles and models, and then compare this to the current-state of the company, identifying gaps and using these gaps as insights to influence plans going forward.

Therefore, we can see Enterprise Architecture as the bridge between defining a strategy, and its implementation.

One of the benefits of Enterprise Architecture in strategy implementation is transparency. How well strategy is communicated is an essential component of getting it right. Oftentimes, those formulating a strategy and those implement it are different people, in different departments, with different expertise. A common problem, as departments in organizations often work in ‘silos’ – parts of a larger whole working in separation to one another. This disparity is a hotbed for disconnections in data and ideas, and in turn, limited (or none at all) success in implementing strategy.

Well integrated collaboration support in Enterprise Architecture serves to align the relevant parties by keeping everyone up to date. It also benefits the business by applying a consensually agreed upon, and stable framework in which all parties can build on efficiently.

Strategic Planning Lifecycle

The figure above demonstrates EA’s place at the heart of strategy and implementation. Enterprise Architecture intercepts the various steps in planning and delivery. It provides analysis to highlight the more critical areas of attention, highlighting which projects should be prioritized. Additionally, EA also serves to align the various stages involved in delivery, through well structured governance of the architecture at large.

Strategic Planning and Business Outcomes

Gartner have often spoken about business outcome driven EA. The mantra is an attempt to shed some of the baggage in how enterprise architecture is conveyed to those outside the discipline.

EA has historically struggled with its perception as an ‘ivory tower’ technology discipline. Therefore, a business outcome approach is beneficial as it makes the end goal and benefits to the organization more clear to management and other stakeholders.

This approach benefits heavily from the ‘just enough‘ approach to enterprise architecture – also referred to as agile enteprise architecture – and focuses predominantly on what the business needs, and what the IT Organization must do to support it.

Business Outcome Driven EA Gartner

As indicated by the graphic above, strategy is at the root of this approach. Organizations must decide on their goals and direction, and then communicate this to the enterprise architecture team.

From here, the EA team can considering their business capabilities and map them out to the different Business Plans levels, before moving on to strategy implementation.

The Strategic Planning Timeline

The first point of call on the strategic planning timeline is to consider the corporate vision. This vision usually details things such as how the business leaders and other relevant stakeholders, think the company will differentiate itself from the competition; and the perceived value of the companies services and/or products (in the eye of the customer) compared to their competition.

Ideas pertaining to the transformation of the business are then weighted by their value in relation to the corporate vision. From here, the relevant resources needed to action such ideas are considered, and eventually compared to what the company already has.

For example, a business may decide that a better on-boarding process would help achieve its vision of being a leader in customer experience. One such way this could be achieved is through a more intuitive trialing and feedback platform. Subsequently, the business would analyze its current on-boarding process to highlight where it falls behind the newly established ideal. Transition planning would then be actioned to determine how the gap between the current process, and the ideal can be addressed.

Without enterprise architecture or strategic planning, these ideas are arguably only good for white board decorations. Attempts to implement the new strategy will likely result in a number of false starts, or even failure to get off the ground at all as essential considerations are overlooked, plans are rushed into action and the various organizational silos all pull in different directions.

With an enterprise architecture solution, however, ideas can graduate from the whiteboard, become almost tangible targets that departments can envision and work towards. With everybody on the same page and pulling in the same direction, not to mention the decreased likelihood of unwelcome surprises upon implementation, the whole process becomes a lot more manageable.

enterprise architecture business process

Categories
erwin Expert Blog Enterprise Architecture

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

A Business Outcome Driven Enterprise Architecture Approach

Experts are invaluable. They’re the people who have demonstrated time and time again that they can be trusted in their relevant field. However, dialogue between experts and non-experts is not always as straightforward as we’d like it to be.

We’ve all experienced it, and perhaps we’ve also been guilty of it ourselves – that is, speaking about a topic with the presumption that your audience is already caught up.

Enterprise architecture (and its architects) is no different in this regard, and perhaps more guilty than most. Enterprise Architects (EA) can often fall into the trap of demonstrating the technical wizardry behind building processes, and understandably so. This is the side of EA than an Enterprise Architect sees.

However, this generally isn’t the side that stakeholders want to see. Perhaps this is a crude analogy, but in health, you’re not too concerned with the biology behind why you’re all bunged up. The experts know why, but you just want to feel better.

You just want the outcome.

Enterprise architecture is no different. In this case, patients stakeholders want to see the solution. They want to see how a new or revised enterprise architecture initiative will bring the organization closer to it’s desired business outcomes.

This is why the traditional, standardized framework-centric take on EA has its limits (but that doesn’t mean enterprise architecture frameworks are obsolete). IT thought leader and leading Gartner researcher, Brian Burke (above) previously shed some light on this:

“Focusing on a standard EA framework doesn’t work,” he said. “In the past EA practicioners focused on deliverables that were useful to enterprise architects but not valuable to senior management and/or did not respond to a specific business IT need.

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

Brian Burke’s statements are echoed across the industry. Enterprise architecture has got to become more about business outcomes and the deliverables that steer an organization toward them.

Enterprise Architecture Deliverables

Gartner have actually outlined the deliverables behind the wheel – categorizing five different deliverables that will aid in EAs delivering business value.

Measurable Deliverables – Deliverables that measure EAs direct impact on a business.

Actionable Deliverables – Deliverables that drive change in relation to business outcomes.

Diagnostic Deliverables – Analytic tools purposed for determining the knock on effects of business decisions.

Enabling Deliverables – The collected information (e.g. from performance metrics) that enable diagnostic deliverables. Essentially the basis on which the analysis in diagnostic deliverables is formed.

Operational Deliverables – Deliverables focused internally, on the EA teams themselves. They help define where an EA team is now and an outline of what should be done to move forward.

Just Enough Enterprise Architecture

Frameworks can still be implemented, however. But they should be implemented malleably, as opposed to being rigid as not to undermine EAs rule of best practice – “Just Enough” enterprise architecture .

“Just enough” enterprise architecture is an EA mantra for avoiding the problems that come with over analysis. Problems such as delayed decision making and missed opportunity thanks to a symptom colloquially dubbed “analysis paralysis.”

A deliverable/business outcome approach can help address which tangents are most important to the organization, and therefore indicate which is best to follow. Then, rather than doing everything in a blanket, one size fits all take on EA, enterprise architects can be far more precise, saving themselves time, and moving projects through the pipeline more quickly.

Business Outcome Driven EA and Alignment

A businesses outcome based approach to EA will also help align the business needs with the IT department as a whole. By focusing on what the business needs, you’ll be able to prime the IT & Technology services, as well as application portfolios in order to achieve what you set out to do in order to progress as departments, and the organization as a whole.

Business Outcome EA and Innovation

Innovation is becoming increasingly more important in business. It should now, ideally, permeate every inch of an organization both encouraging and enabling innovation indiscriminately across processes. Enterprise architecture is no different in this regard – there’s even a case for innovation being even more important to EA, as they administer the foundations in which to implement new ideas.

The business outcome approach to EA, can provide a platform upon which innovation can be carried out.

enterprise architecture business process

Categories
Enterprise Architecture erwin Expert Blog

How Does a Vanguard Enterprise Architect Manage Innovation?

We should move away from the ‘burden of innovation’ expression. Innovation is born of free thought, expression and creativity, and to label such a notion a ‘burden’ has always seemed a bizarre turn of phrase.

Of course, some people are naturally better at innovation than others, and those that struggle with the discipline may feel burdened with pressure if you demand innovation from them. But it’s unlikely that either employees or business leaders will feel oppressed by the notion that their good ideas will have a positive impact on the business.

Gartner: “By 2016, 30% of global organizations will establish a clear role distinction between Foundational and Vanguard Enterprise Architects.”

It’s for these reasons why Enterprise Architecture going forward, needs to adopt the Vanguard Enterprise Architect.

An innovation driver, the Vanguard enterprise architect deals with technology disruptions and enterprise connectivity; as opposed to the Foundational Enterprise Architect, who maintains enterprise technology and the systems of record.

Gone are the days whereby innovation is managed by a small group (i.e  a Research and Development team). We now welcome an era of collaboration, enabled by the speed and quality of communication the Internet can offer, and further enhanced by the Cloud.

With digital business, innovation should (and will) permeate every aspect of business – Enterprise Architecture included. In fact, Enterprise Architecture will arguably be the most imbued business department, due to their governance over steering innovation for the business as a whole.

EA’s will have to manage the current state of the business, but now the non-linear tasks attributed to digital business are also a duty. These are two very different responsibilities and therefore, not only warrant, but demand two clearly defined and distinguished roles.

Bimodal IT

Bimodal IT is a business mantra whereby an organization fundamentally acknowledges the separation between new and old IT. The reason for its inception, is the maturing role of IT within organizations. Over time, we can see that IT has evolved, indicating it’s taken on new responsibilities, but hasn’t shed the old ones.

It’s become more capable and more essential, and so the tasks IT departments have to carry out have grown, rather than changed. Bimodal is a method of acknowledging this evolution, and effectively coping with it.  This is why colloquially, bimodal IT has been summarized as having your cake (old IT) and eating it too (new).

It accounts for two ‘modes’. Mode 1 being the more traditional, responsible for “keeping the lights on” – the cost savings, efficiency improving, core tasks we’re used to from IT.

Mode 2 on the other hand, is responsible for ‘new IT’ tasks, like innovation and businesses more disruptive factors. Sound familiar?

That’s because bimodal IT is closely aligned with the idea of a Vanguard EA. In fact, for either to work at their full potential, both should be employed in tandem.

The separation between the two modes and the two roles shouldn’t get in the way though. With well actioned collaboration, organizations can ensure their processes are carried out in the open for the relevant parties.

If teams behind both modes, and Enterprise Architects occupying either role (Foundational or Vanguard) are aware of what one another are doing and even share resources in order to help one another, the system becomes frictionless. This effectively blurs the antithetic nature of the disciplines as in the end, everybody is still working towards bettering the business and it’s operations.

Bimodal Mode 1 and 2

The above shows the differences between the two modes. Most prominent perhaps, is the increased IT agility awarded by Mode 2. In an ever changing field such as digital business, agility should be a priority for any organization.

Benefits of Enterprise Architecture Tools in Bimodal IT

A good Enterprise Architecture tool (or digital business platform) can aid the alignment of the two modes. You’ll be able to clearly identify the different assets associated with the modes, as well as facilitate improved communication between the relevant parties.

The benefits don’t end here though.

With an efficient, agile EA tool, planning can becoming more accurate and reliable through the well applied use of roadmaps; you’ll be better equipped to understand the impact and costs of change; business and IT assets can be standardized so everyone is always on the same page – facilitating better communication; the traceability of objectives to projects will be improved, increasing visibility; and with all this in mind, collaboration between individuals and teams will benefit too. And that’s just the tip of the iceberg.

enterprise architecture business process

Categories
erwin Expert Blog Enterprise Architecture

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

Using Enterprise Architecture Models, Views & Diagrams

Models and views are fundamental to managing and communicating enterprise architecture (EA).

Enterprise Architecture Models

A model represents the data for an organization that describes the architectural concepts. It is based upon the underlying meta-model provided by an enterprise architecture framework.

Having a consistent underlying model allows an organization to have an authentic representation of its information – an advantage not afforded by the ad-hoc, spreadsheet and presentation tool approach to enterprise architecture (a.k.a, the “Office Tools approach”).

Enterprise architecture models represent the structure of an organization and how the technologies and other assets that power the organization are interconnected. An enterprise architecture model is the foundational representation of this information. The blueprint.

Therefore, an understanding of enterprise architecture views and diagrams has to start here. That is because views and diagrams are ultimately just different ways of communicating the information in a model.

By filtering the information present in the model, views and diagrams can help involve less technical stakeholders and provide the organization more generally with a new perspective, more comprehensive insight and greater opportunities for process and technological improvements.

Enterprise Architecture Views

A view is a work product that can be used to communicate, analyze and manage EA models. Most frameworks include a default set of views. The ArchiMate® specification from the Open Group provides a set of views along with their underlying notation so that you can recognize a concept from its visualization.

Using different views allows an organization to represent a model from different perspectives – or viewpoints. These alternative viewpoints on a model allows organizations to focus on specific concerns regarding the model. They can also suppress irrelevant information and detail to provide a simplified, more easily digestible model.

For example, a financial portfolio viewpoint focuses on financial portfolio concerns and a financial portfolio viewpoint model contains those elements that are related to financial concerns from a more general model.

Views allow you to manage the abstraction of a model so that it is relevant to different stakeholders. A business stakeholder may have a high level goal oriented viewpoint and a software developer may have a detailed technical viewpoint of a model.

Views are represented in different ways according to stakeholder needs. In this article, we are focusing on diagrams, which are a common way for most enterprise architecture frameworks to represent views.

In later articles, we will cover other types of views such as pivot tables, charts, Kanban boards and roadmaps that are all different perspectives on the underlying model.

Metamodel and views
Figure 1: Multiple views for a single model

Figure 1 shows some sample views of a subset of the meta-model. Here we are showing application components and assignments to locations.

You can see that there are many different views of the architecture depending on stakeholders needs.

Enterprise Architecture Diagrams

Diagrams provide a view of the underlying repository concepts and their associations. The open Group ArchiMate® 2.1 specification contains a core set of views, an implementation and migration extension and motivation views.

These are the example views provided by the Open Group. However, ArchiMate® is not limited to just this collection of views. You may also create your own views (meta-diagrams) to suit your own purposes.

Enterprise Architecture Layered View
Figure 2: Example layered view

Figure 2 is an example ‘layered’ view from ArchiMate®. The layered view is useful as it contains nearly all of the meta-types and meta-associations in the ArchiMate® meta-model. You can see on this view that we are focusing in the center on the ‘Upgrade Claims Handling’ work package. We’re also showing the connected associations that this work package has to other concepts.

The other concepts include the driver (Customer satisfaction), goal (Revise claim handling process), application component (Call center application), deliverable (Upgraded website for claims handling), requirement (All claims shall be submitted online) business service (Faster claims handling) and role (Claim reviewer). Each of these associations are different and are represented in a different graphical manner.

The layered view is also useful for showing the layers between the different domains of the architecture.

ArchiMate layered view showing layers
Figure 3: ArchiMate layered view showing layers

In Figure 3, the layers are depicted with different colors. Yellow icons represent the business layer, blue icons for the application layer and green icons for the technology layer.

Representational Consistency

Many of these viewpoints can be created by hand or in a drawing tool, however, a major benefit of having a model and ideally a repository-based tool is that your views are consistent. That is, they are represented directly based upon the associations in the repository.

No matter what type of view, the information should always be representationally consistent with the model. However, for the sake of visibility, it is a good idea to sometimes hide associations and detail in views to match stakeholder needs.

Metamodel and views
Figure 4: ArchiMate viewpoints mapped to a model

In Figure 4, we can see that we have two very different viewpoints for the same underlying meta-model.

The ArchiMate® Stakeholder Viewpoint shows the drivers and assessments. You can see that some of the same concepts are represented in the ArchiMate® Motivation Viewpoint which is showing the overall motivational strategy for our business.

All associations that are shown exist in the repository. When a diagram is created, you should expect your tool to show the associations that exist between two concepts automatically.

Custom Views

Architecture frameworks such as ArchiMate® and TOGAF® provide a set of views. In the case of ArchiMate®, the views are example views and ones which a user of the framework may find useful.

Most of the enterprise architecture frameworks are designed to support custom views. That is, a set of views that helps a stakeholder comprehend the architecture.

Summary

Views provide a representational consistent view of the underlying model. Views can contain as much detail or as little detail necessary to communicate the model to the appropriate stakeholder.

Diagrams are the most popular form of views and ArchiMate® provides a standard notation for the communication of views. The benefit of this being that each stakeholder has the same understanding of any concept. This is much like any builder will be able to understand any set of building plans no matter who the author is as they use the same design standards.

Enterprise architecture review

Categories
erwin Expert Blog Enterprise Architecture

Guide: Enterprise Architecture Frameworks & Meta-Models

In much the same way as any building or infrastructure project requires different stakeholders and different plan views, enterprise architecture (EA) requires the same.

You wouldn’t build a house without understanding the building architecture, pipe-works, electricity plans, ground plans, all within the context of each other. It provides the plans for different views of the enterprise. Enterprise architecture frameworks describe the standard views that an organization can expect to see.

Enterprise Architecture Discipline

The discipline of EA, views an organization as an overall system of complex and intertwined systems. Effective management of such complexity and scale requires tools and approaches that architects can use. An architecture framework provides the tools and approaches necessary to abstract this information to a level of detail that is manageable.

A framework helps bring enterprise design tasks into focus and produces valuable architecture description documentation. The components of an architecture framework provide structured guidance that is divided into four main areas:

Architecture description:

How to document the enterprise as a system from different viewpoints. Each view describes one domain of the architecture; it includes those meta-types and associations that address particular concerns of interest to particular stakeholders; it may take the form of a list, a table, a chart, a diagram, or a higher level of composite of such.

Architecture notation:

How to visualize the enterprise in a standard manner. Each view can be represented by a standard depiction that is understandable and communicable to all stakeholders. one such notation is ArchiMate® from the open group.

Design method:

Processes that architects follow. Usually, an over arching enterprise architecture process, composed of phases, breaks into lower-level processes composed of finer grained activities. A process is defined by its objectives, inputs, phases (steps or activities) and outputs. Approaches, techniques, tools, principles, rules, and practices may support it. Agile architecture is one set of supporting techniques.

Team organization:

Guidance on the team structure, the governance of the team, the skills, experience and training needed. Kanban boards and agile architecture can help provide team structure, governance and best practice.

Enterprise architecture review

Types of Enterprise Architecture Framework

There are a number of popular enterprise architecture frameworks available:

  • ArchiMate – An open Group Architecture Framework – a widely used framework that includes a notation for visualizing architecture. May be used in conjunction with TOGAF®.
  • TOGAF – The Open Group Architecture Framework – a widely used framework including an architectural Development Method and standards for describing various types of architecture.
  • DoDAF – The Department of Defense Architecture Framework – the standard for defense architectures especially in the United states.
  • MoDAF – The Ministry of Defense Architecture Framework – the UK standard for defense architectures.
  • NAF – the NATO Architecture Framework – a standard adopted for NATO allies.
  • FEAF – A federal enterprise architecture framework issued by the US Federal CIO council.
  • FEA – the 2002 Federal Enterprise Architecture (FEA) guidance on categorizing and grouping IT investments (issued by the US Federal Office of Management and Budget).
  • Zachman Framework – a classification scheme for EA artifacts launched in the early 1980s by John Zachman – often considered the father of enterprise architecture.
  • TM FORUM – Telemanagement forum – standard reference architecture models for the telecoms industry.

Enterprise Architecture Meta-Models

A meta-model is a description of a classification of a set of things. It describes the types of things (meta-types), the rules between them (associations) and the attributes that describe them. Meta-models can usually be built to describe any type of problem or scenario.

They are often graphical and are represented by boxes and lines. Boxes indicate the metatypes and lines represent the associations. Meta-models are used by end users to express models.

In the Figure 1 meta-model example below, we could describe the relationship between a Pilot, Airline and Aircraft.

Meta-model
Figure 1: Meta-model

In the model in Figure 2 below, we use the meta-model to guide the construction of the model. The meta-model provides the framework within which the model can be constructed. We call the instances of the meta-types – Concepts.

Model
Figure 2: Model

Each enterprise architecture framework will usually have an underlying meta-model that describes its meta-types and associations. An example of a meta-model for innovation management is shown here in Figure 3.

Innovation management meta-model
Figure 3: Innovation management meta-model

In Summary

This article covered the core concepts for meta-models and associations. Meta-models are the core building blocks for any architecture framework. They provide the basis for rigor and consistency for model data. Without an enterprise architecture meta-model, the whole management of enterprise architecture becomes extremely difficult.

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