Category: Enterprise Architecture

The very best, best practice guides and advice for professionals and organizations interested in enterprise architecture.

Categories
Data Intelligence Data Modeling Business Process Enterprise Architecture erwin Expert Blog

Benefits of Enterprise Modeling and Data Intelligence Solutions

Users discuss how they are putting erwin’s data modeling, enterprise architecture, business process modeling, and data intelligences solutions to work

IT Central Station members using erwin solutions are realizing the benefits of enterprise modeling and data intelligence. This article highlights some specific use cases and the results they’re experiencing within the organizations.

Enterprise Architecture & Business Process Modeling with erwin Evolve

An enterprise architect uses erwin Evolve at an aerospace/defense firm with more than 10,000 employees. His team is “doing business process modeling and high-level strategic modeling with its capabilities.” Others in his company are using it for IT infrastructure, such as aligning requirements to system solutions.

For Matthieu G., a senior business process management architect at a pharma/biotech company with more than 5,000 employees, erwin Evolve was useful for enterprise architecture reference. As he put it, “We are describing our business process and we are trying to describe our data catalog. We are describing our complete applications assets, and we are interfacing to the CMDB of our providers.”

His team also is using the software to manage roadmaps in their main transformation programs. He added, “We have also linked it to our documentation repository, so we have a description of our data documents.” They have documented 200 business processes in this way. In particular, the tool helped them to design their qualification review, which is necessary in a pharmaceutical business.

erwin Evolve users are experiencing numerous benefits. According to the aerospace enterprise architect, “It’s helped us advance in our capabilities to perform model-based systems engineering, and also model-based enterprise architecture.”

This matters because, as he said, “By placing the data and the metadata into a model, which is what the tool does, you gain the abilities for linkages between different objects in the model, linkages that you cannot get on paper or with Visio or PowerPoint.” That is a huge differentiator for this user.

This user also noted, “I use the automatic diagramming features a lot. When one of erwin’s company reps showed that to me a couple of years ago, I was stunned. That saves hours of work in diagramming. That capability is something I have not seen in other suppliers’ tools.”

He further explained “that really helps too with when your data is up to date. The tool will then automatically generate the updated diagram based on the data, so you know it’s always the most current version. You can’t do that in things like Visio and PowerPoint. They’re static snapshots of a diagram at some point in time. This is live and dynamic.”

erwin DM

Data Modeling with erwin Data Modeler

George H., a technology manager, uses erwin Data Modeler (erwin DM) at a pharma/biotech company with more than 10,000 employees for their enterprise data warehouse.

He elaborated by saying, “We have an enterprise model being maintained and we have about 11 business-capability models being maintained. Examples of business capabilities would be finance, human resources, supply-chain, sales and marketing, and procurement. We maintain business domain models in addition to the enterprise model.”

Roshan H., an EDW architect/data modeler who uses erwin DM at Royal Bank of Canada, works on diverse platforms, including Microsoft SQL Server, Oracle, DB2, Teradata and NoSQL. After gathering requirements and mapping data on Excel, they start building the conceptual model and then the logical model with erwin DM.

He said, “When we have these data models built in the erwin DM, we generate the PDF data model diagrams and take it to the team (DBA, BSAs, QA and others) to explain the model diagram. Once everything is reviewed, then we go on to discuss the physical data model.”

“We use erwin DM to do all of the levels of analysis that a data architect does,” said Sharon A., a senior manager, data governance at an insurance company with over 500 employees. She added, “erwin DM does conceptual, logical and physical database or data structure capture and design, and creates a library of such things.

We do conceptual data modeling, which is very high-level and doesn’t have columns and tables. It’s more concepts that the business described to us in words. We can then use the graphic interface to create boxes that contain descriptions of things and connect things together. It helps us to do a scope statement at the beginning of a project to corral what the area is that the data is going to be using.”

Data Governance with erwin Data Intelligence

IT Central Station members are seeing benefits from using erwin Data Intelligence (erwin DI) for data governance use cases. For Rick D., a data architect at NAMM, a small healthcare company, erwin DI “enabled us to centralize a tremendous amount of data into a common standard, and uniform reporting has decreased report requests.”

As a medical company, they receive data from 17 different health plans. Before adopting erwin DI, they didn’t have a centralized data dictionary of their data. The benefit of data governance, as he saw it, was that “everybody in our organization knows what we are talking about. Whether it is an institutional claim, a professional claim, Blue Cross or Blue Shield, health plan payer, group titles, names, etc.”

A solution architect at a pharma/biotech company with more than 10,000 employees used erwin DI for metadata management, versioning of metadata and metadata mappings and automation. In his experience, applying governance to metadata and creating mappings has helped different stakeholders gain a good understanding of the data they use to do their work.

Sharon A. had a comparable use case. She said, “You can map the business understanding in your glossary back to your physical so you can see it both ways. With erwin DI, I can have a full library of physical data there or logical data sets, publish it out through the portal, and then the business can do self-service. The DBAs can use it for all different types of value-add from their side of the house. They have the ability to see particular aspects, such as RPII, and there are some neat reports which show that. They are able manage who can look at these different pieces of information.”

For more real erwin user experiences, visit IT Central Station.

Categories
erwin Expert Blog Enterprise Architecture

Enterprise Architecture vs. Technical Architecture

The most straightforward way to convey the difference between technical architecture and enterprise architecture (EA) is by looking at the scope and focus of each.

As the name suggests, technical architects are more concerned with the technicalities and the specifics of a particular technology than with technology’s place in the enterprise.

That’s not to say that they operate without the enterprise’s overall strategy in mind. They do – or should ­– but the direction for said strategy typically comes from elsewhere. Most significantly – from an enterprise architect.

In this post:

Enterprise architecture review

What Is a Technical Architect?

A technical architect works closely with development teams in a supervisory capacity – providing leadership and guidance during the project lifecycle.

They often work under more specific titles, reflecting the technology they specialize in – e.g., “Java architect” or “Python architect.”

Typically, their operations revolve around technical services and in the context of the project lifecycle – enabling technology.

It’s a role that requires good communication and relationship management skills, as well as the ability to anticipate problems, manage their time, and operate under pressure.

The Difference Between Technical Architecture and Enterprise Architecture

We previously have discussed the difference between data architecture and EA plus the difference between solutions architecture and EA.

In the latter, we described enterprise architects as having a “holistic view” of the organization, mostly focusing on things from a high-level, strategic point of view.

Although technology is something that enterprise architects are concerned with, they aren’t expected to have a deep, ground-level understanding of the tech itself.

Their broad scope and holistic view of the enterprise does not allow for this.

Technical architecture can be seen as the antithesis to this. Instead of seeing the organization from a high-level, strategic point of view, technical architects operate amongst the weeds.

They have a high focus on technology, and a low focus on how that technology fits in with the enterprise’s overall strategy.

Using an orchestra as an analogy, enterprise architects would assume the role of a conductor who is less concerned with how any individual instrument operates but requires they work together cohesively to complete the performance.

While enterprise architects have a high strategy focus, they are less detail orientated., Technical architects operate in the reverse, with solution architects somewhere in the middle.

Enterprise Architecture vs. Technical Architecture – Which One Do I Need?

Well? … Both.

It’s a straightforward and somewhat vague answer. But it’s one that needs to be given, because we’re asking the wrong question.

In a world where organizations are increasingly data-driven, any ambition to scale will inevitably scale with the complexities of the systems involved too.

With this considered, we should abandon the binary question, in favor of asking “when”  instead of “which.”

When do I need enterprise architecture? When do I need technical architecture?

The answer to both is “sooner, rather than later.”

With regard to enterprise architecture, many organizations  already are doing enterprise architecture before they have a formally recognized enterprise architecture initiative or enterprise architecture tool.

We consider these efforts “low-maturity” enterprise architecture.

But doing enterprise architecture this way can cause bottlenecks as an organization’s enterprise architecture scales. Additionally, this sort of enterprise architecture is vulnerable in its dependency on individuals.

Without a formalized approach to enterprise architecture, the whole enterprise architecture could collapse if the person in charge of the EA were to leave without contingency plans in place.

You may already be at and the point of experiencing bottlenecks. If so, you should consider formalizing your enterprise architecture approach and investing in an enterprise architecture management suite (EAMS) now.

This 2020 Forrester Report on EAMS is a great place to start your research.

The need for technical architecture implies an organization already has a complex enterprise architecture and some degree of formalization for managing it.

This, in turn, implies an organization is large and therefore has more complicated product lifecycles and higher stakes implementation procedures for new tech.

In either case, managing an organization’s enterprise architecture through manual processes and repurposed systems – some organizations attempt to make do with managing their EA via PowerPoint slides and sticky notes – is not the recommended approach.

For a scalable, manageable and efficient approach to enterprise architecture, organizations should adopt a dedicated enterprise architecture tool.

erwin Evolve is one such tool that also supports business process modeling use cases.

erwin Evolve has collaborative features at its core, meaning organizational silos that had once kept EA in an ivory tower are broken down, and the holistic view of enterprise architects is enhanced.

With erwin Evolve, users enjoy the following benefits:

  • Creation and visualization of complex models
  • Powerful analytic tools to better understand an organization’s architecture – such as impact analysis
  • Documentation and knowledge retention for better business continuity
  • Democratization of the decision-making process
  • Greater agility and efficiency in implementations and dealing with disruption
  • Lower risks and costs driven by an enhanced ability to identify redundant systems and processes

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

For more information on enterprise architecture, click here to get the erwin experts’ definitive guide to enterprise architecture – 100% free of charge.

Categories
Enterprise Architecture erwin Expert Blog

The Difference Between Enterprise Architecture and Solutions Architecture

Despite the similarities in name, there are a number of key differences between enterprise architecture and solutions architecture.

Much like the differences between enterprise architecture (EA) and data architecture, EA’s holistic view of the enterprise will often see enterprise and solution architects collaborate.

And as with data architecture, a solution architect’s focus is narrower.

In this post:

What Is a Solutions Architect?

Solutions architecture is about solving problems. It describes the process of orchestrating software engineering to address an organization’s needs.

Typically, a solution architect’s responsibilities cover:

  • Assessing and understanding an organization’s technological assets
  • Finding a solution to address a problem
  • Defining and denoting the critical technologies for the organization’s operations
  • Understanding the impact of time on the current technologies in place, including establishing what can be scaled and what must be replaced/upgraded
  • Designing prototype solutions
  • Assessing and selecting new technologies

Their technical skills typically include software engineering and design, DevOps, business analysis and increasingly, cloud architecture.

What Is an Enterprise Architect?

Broadly speaking, enterprise architecture is a strategic planning initiative.

Enterprise architects are concerned with how they can reduce costs, eliminate redundancies in technology and processes, and prepare for, mitigate and manage the impact of change.

To operate effectively, enterprise architects must have a solid understanding of the organizations they work with/for.

Such an understanding has its advantages, but it also means that there isn’t the scope to be concerned with the more “technical” side of an organization’s architecture.

Typically, an enterprise architect’s responsibilities cover:

  • Understanding and developing the whole enterprise architecture
  • Evaluating risks and the impacts of change and creating a roadmap with such evaluations considered
  • Ensuring alignment between the business and IT through the organization’s enterprise architecture
  • Advising decision-makers and business leaders from an organization-wide, holistic perspective of the enterprise

From this perspective, solution architecture’s value to enterprise architecture becomes even more clear. Where an enterprise architect is concerned with the EA’s current state, and the strategy to reach the desired future-state, solutions architects act on that strategic direction.

Enterprise Architecture Tools

Enterprise Architects vs. Solutions Architects

Perhaps it’s misleading to use “versus” to describe the difference between enterprise architecture and solutions architecture. They are very much collaborators in the organization and should not be looked at as competitive in terms of which provides more value.

A better way of highlighting the difference between the two is through their focus on strategy vs. technology.

A focus on strategy implies a broad understanding of the mechanics of any given technology. This is because there is a lot more to strategy than just the technology needed to implement it. A skewed focus on technology would mean that the processes, people and other variables required to inform strategy are ignored.

Conversely, a focus on technology is necessary to ensure implementations and operations can run smoothly. By its nature, it is more “in the weeds” and so the necessary holistic perspective of the organization can be harder to understand and/or account for.

With their holistic view of the organization, enterprise architects take on the strategy. They then use their strategic planning perspective to inform and delegate to solutions architects.

In the same vain, a technical architect has a low strategic focus and a high technological focus.

Bottom line,  an enterprise architect’s strategic focus is high and their technology focus is low; technology architects operate in the reverse; and solution architects bridge the two.

The Imperative for Enterprise Architecture and Solutions Architecture

With the quickening pace of digital transformation and the increased acceleration owed to the Covid-19 crisis, enterprise architects and solution architects are becoming increasingly relevant.

“Enterprise architect” was named the top tech job in the UK for 2020 and as this article implies, solution architects should stand to benefit, as well.

However, simply hiring enterprise architects and solution architects isn’t enough. Enterprise architecture in particular has been blighted by its perception as a role operating in an ivory tower, disconnected from the wider business.

Considering IT and business alignment is a core tenant of an enterprise architect’s responsibilities, this is obviously counter-productive.

For many organizations, shaking this perception will require a change in how enterprise architecture is done. Organizations need a definable, measurable and collaborative approach to enterprise architecture to make the most out of its vast potential.

This means moving away from low maturity examples of enterprise architecture that are managed through a hodgepodge of repurposed tools, and decentralized notes.

erwin is helping organizations mature their EA with erwin Evolve. With Evolve, organizations can collaborate within a purpose-built enterprise architecture tool for both greater consistency and involvement from the wider business.

As part of the wider erwin Enterprise Data Governance Experience (EDGE), erwin Evolve lets organizations synergize their enterprise architecture with their data governance and management strategies.

This means that efforts to manage the enterprise architecture include a data inclusive perspective. And considering data’s value as an asset, this perspective is vital.

It means an organization can get a clear and full picture of the whole data lifecycle in relation to the systems and broader context it exists in, so that the intersections between data and the organization’s assets is clearer.

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

For more information on enterprise architecture, click here to get the erwin Experts’ definitive guide to enterprise architecture – 100% free of charge.

Categories
Enterprise Architecture erwin Expert Blog

Using Enterprise Architecture for Integration After Mergers and Acquisitions

Because of its holistic view of an organization, enterprise architecture and mergers & acquisitions (M&A) go hand-in-hand.

M&A activity, despite or in light of COVID-19, are on an upswing. The Financial Times reported Google, Amazon, Apple, Facebook and Microsoft have made 19 deals so far this year, according to Refinitiv, the London-based global provider of financial market data. This represents the fastest pace of acquisitions and strategic investments since 2015.

Let’s face it, company mergers, even once approved, can be daunting affairs. Depending on the size of the businesses involved, hundreds of systems and processes need to be accounted for, which can be difficult and often impossible to do in advance.

Following these transactions, businesses typically find themselves with a plethora of duplicate applications and business capabilities that eat into overhead and complicate inter-departmental alignment.

These drawbacks mean businesses have to ensure their systems are fully documented and rationalized. This way the organization can comb through its inventory and make more informed decisions on which systems can and should be cut or phased out, so it can operate closer to peak efficiency and deliver the roadmap to enable the necessary change.

enterprise architecture innovation management

Enterprise Architecture Needs a Seat at the Table

IT professionals have the inside track about the connection that already exists across applications and data – and they’ll be the ones tasked with carrying out whatever technical requirements are in order post-acquisition.

But despite this, they’re rarely part of M&A tech strategy discussions and the synergy between enterprise architecture and mergers & acquisitions is overlooked. That should change.

With IT leaders involved from the start, they can work with the CFO and COO teams on assessing systems and providing advice on costs that might not otherwise be fully accounted for, such as systems and data integration.

Additionally, by leveraging mergers and acquisitions tools in the beginning, IT can provide a collaborative platform for business and technical stakeholders to get a complete view of their data and quickly visualize and assess what’s in place across companies, as well as what integrations, overlaps or other complexities exist.

This is why enterprise architecture for mergers and acquisitions is essential.

EA helps organizational alignment, providing a business-outcome perspective for IT and guiding transformation. It also helps a business define strategy and models, improving interdepartmental cohesion and communication.

Enterprise Architecture roadmaps can also be leveraged to provide a common focus throughout the company, and if existing roadmaps are in place, they can be modified to fit the new landscape.

EA aids in rooting out duplications in processes and operations, making the business more cost efficient on-the-whole.

Two Approaches to Enterprise Architecture

The Makeshift Approach

The first approach is more common in businesses with either no or a low-maturity enterprise architecture initiative. Smaller businesses often start out with this approach, as their limited operations and systems aren’t enough to justify real EA investment. Instead, businesses opt to repurpose tools they already have, such as the Microsoft Office Suite.

This comes with its advantages that mainly play out on a short-term basis, with the disadvantages only becoming apparent as the EA develops. For a start, the learning curve is typically smaller, as many people are already familiar with software, and the cost per license is relatively low when compared with built-for-purpose EA tools.

These short-term advantages will be eclipsed overtime as the organization’s EA grows. The adhoc Office tools approach to EA requires juggling a number of applications and formats that can stifle effectiveness.

Not only do the operations and systems become too numbered to manage this way, the disparity between formats prevents deep analysis. It also creates more work for the enterprise architect, as the disparate parts of the Office tools must be maintained separately when changes are made, to make sure everything is up to date.

This method also increases the likelihood that data is overlooked as key information is siloed, and it isn’t always clear which data set is behind any given door, disrupting efficiency and time to market.

It isn’t just data that siloed, though. The Office tools approach can isolate the EA department itself, from the wider business as the aforementioned disparities owed to the mis-matching formats can make collaborating with the wider business more difficult.

The Dedicated Approach

As an organization’s enterprise architecture grows, investing in dedicated EA tools becomes a necessity, making the transition just a matter of timing.

With a dedicated enterprise architecture tool, EA management is much easier. The data is all stored in one place, allowing for faster, deeper and more comprehensive analysis and comparison.

See also: Getting Started with Enterprise Architecture Tools

Collaboration also benefits from this approach, as having everything housed under one roof makes it far easier to share with stakeholders, decision-makers, C-level executives and other relevant parties.

Benefits of Enterprise Architecture for Mergers & Acquisitions

While organizational mergers can be fraught with many challenges. they don’t have to be so hard.

Enterprise architecture is essential to successful M&A. EA helps document and manage this complexity, turning all this data into meaningful insights.

It helps alignment by providing a business-outcome perspective for IT and guiding transformation. It also helps define strategy and models, improving interdepartmental cohesion and communication.

Roadmaps can be used to provide a common focus throughout the new company, and if existing roadmaps are in place, they can be modified to fit the new landscape.

erwin Evolve is a full-featured, configurable set of enterprise architecture and business process modeling and analysis tools. Use erwin Evolve to effectively tame complexity, manage change, and increase operational efficiency.

enterprise architecture business process

Categories
erwin Expert Blog Enterprise Architecture

What Is the Analytic Hierarchy Process?

The analytic hierarchy process (AHP) or pairwise comparison is a framework for decision making, rooted in mathematics and psychology. The widely used technique was created by Thomas L. Saaty, a Distinguished University Professor at the University of Pittsburgh, in the 1970s.

Saaty recognized that making decisions is complicated. Knowing how to make the “right” decision is even harder. The AHP is applied as an attempt to introduce structure into the organization and analysis of complex decisions.

The aim of the analytic hierarchy process is not to provide just one unique, correct decision.  Rather, the AHP is a framework for structuring a problem (based around decision-making), relating it to overall goals and providing solution alternatives by allowing a group to map a decision to a particular goal or objective.

When applied correctly, the end result should be a rational decision based on the organization’s goals, and any concept can be ranked and compared within the context of a suitable goal.

The Analytic Hierarchy Process in Practice

The application of AHP begins with users decomposing their decision problem into hierarchy sub-criteria, each of which can be analyzed separately.

The concepts within the hierarchy can relate to any aspect of the decision problem; tangible or intangible, carefully measured or roughly estimated, well or poorly understood—anything at all that applies to the decision at hand.

Once the AHP is built, the decision makers (users) systematically evaluate its various elements by comparing them to one another two at a time (Pairwise comparison), with respect to their impact on a concept (criteria) above them in the hierarchy.

In making the comparisons, the decision makers typically use their judgments about the elements’ relative meaning and importance.

It is the fundamental foundation of the AHP technique that human decisions, and not just the underlying data, can be used in performing the evaluations.

Analytic Hierarchy Process/Pairwise Comparison

It is typical that a question is defined at the criteria level of the hierarchy to guide the decision maker in making the qualitative assessment between the two concepts.

For example, “Which idea helps adoption for driving mobile, cloud and social in our company?”

The AHP framework provides a numerical value for each set of concepts that are part of a pairwise comparison. This technique allows diverse and often incommensurable elements to be compared to one another in a rational and consistent way.

This capability distinguishes the AHP from other decision-making techniques.

Once all concepts have been compared, AHP provides an overall ranking for each concept with the context of the entire problem, for each of the decision alternatives. These numbers represent the alternatives’ relative ability to achieve the goal, so they allow a straightforward consideration of the various courses of action.

Although it has benefits for team decision-making, it can be used by individuals working on straightforward decisions. However, the analytic hierarchy process (AHP) is definitely more beneficial where communities of people are working on complex problems.

It has unique advantages when important elements of the decision are difficult to quantify or compare, or where communication among team members is impeded by their different specializations, terminologies, or perspectives.

Some possible ways AHP can be applied to decision making:

Choice: The selection of one alternative from a given set of alternatives, usually where there are multiple decision criteria involved.

Ranking: Putting a set of alternatives in order from most to least desirable

Prioritization: Determining the relative merit of members of a set of alternatives, as opposed to selecting a single one or merely ranking them

Resource allocation: Apportioning resources among a set of alternatives

Benchmarking: Comparing the processes in one’s own organization with those of other best- of-breed organizations

Quality management: Dealing with the multidimensional aspects of quality and quality improvement

Conflict resolution: Settling disputes between parties with apparently incompatible goals or positions

The Analytic Hierarchy Process In Enterprise Architecture

AHP’s rationality, inclusion of the “human factor” and collaborative approach to decision making have made the analytic hierarchy process popular, and it is now used around the world in a wide variety of decision making situations.

One  example is enterprise architecture. Enterprise architects are encouraged to adopt the technique as a best practice.

Much like Kanban boards, the analytic hierarchy process isn’t an idea that grew out of enterprise architecture, but is one that enterprise architects have adopted to meet their needs.

The three key applications of the analytic hierarchy process in enterprise architecture are:

  • Comparing, ranking ideas against each other to work out the most suitable for a goal
  • Ranking initiatives to see which has the most value
  • Comparing workspaces or solution alternatives for the best option

To learn more about enterprise architecture and the analytic hierarchy process, please see our free eBook on Enterprise Architecture and Innovation Management.

enterprise architecture innovation management

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

Enterprise Architecture vs. Data Architecture

Although there is some crossover, there are stark differences between data architecture and enterprise architecture (EA). That’s because data architecture is actually an offshoot of enterprise architecture.

In this post:

See also: The Difference Between Enterprise Architecture and Solutions Architecture 

The Difference Between Data Architecture and Enterprise Architecture

In simple terms, EA provides a holistic, enterprise wide overview of an organization’s assets and processes, whereas data architecture gets into the nitty gritty.

The difference between data architecture and enterprise architecture can be represented with the Zachman Framework. The Zachman Framework is an enterprise architecture framework that provides a formalized view of an enterprise across two dimensions.

Data architecture and Enterprise Architecture - The Zachman Framework

The first deals with interrogatives (who, when, why, what, and how – columns). The second deals with reification (the transformation of an abstract idea into concrete implementation – rows/levels).

We can abstract the interrogatives from the columns, into data, process, network, people, timing and motivation perspectives.

So, in terms of the Zachman Framework, the role of an enterprise architect spans the full schema.

Whereas a data architect’s scope is mostly limited to the “What”(data) and from a system model/logical (level 3) perspective.

The Value of Data Architecture

We’re working in a fast-paced digital economy in which data is extremely valuable. Those that can mine it and extract value from it will be successful, from local organizations to international governments. Without it, progress will halt.

Good data leads to better understanding and ultimately better decision-making. Those organizations that can find ways to extract data and use it to their advantage will be successful.

However, we really need to understand what data we have, what it means, and where it is located. Without this understanding, data can proliferate and become more of a risk to the business than a benefit.

Data architecture is an important discipline for understanding data and includes data, technology and infrastructure design.

Data Architecture and Data Modeling

Data modeling is a key facet of data architecture and is the process of creating a formal model that represents the information used by the organization and its systems.

It helps you understand data assets visually and provides a formal practice to discover, analyze and communicate the assets within an organization.

There are various techniques and sets of terminology involved in data modeling. These include conceptual, logical, physical, hierarchical, knowledge graphs, ontologies, taxonomies, semantic models and many more.

Data modeling has gone through four basic growth periods:

Early data modeling, 1960s-early 2000s.

With the advent of the first pure commercial database systems, both General Electric and IBM came up with graph forms to represent and communicate the intent of their own databases. The evolution of programming languages had a strong influence on the modeling techniques and semantics.

Relational data modeling, 1970s.
Edgar F. Codd published ideas he’d developed in the late 1960s and offered an innovative way of representing a database using tables, columns and relations. The relations were accessible by a language. Much higher productivity was achieved, and IBM released SQL (structured query language).

Relational model adoption, 1980s. The relational model became very popular, supported by vendors such as IBM, Oracle and Microsoft. Most industries adopted the relational database systems and they became part of the fabric of every industry.

Growth of non-relational models, 2008-present. With increasing data volumes and digitization becoming the norm, organizations needed to store vast quantities of data regardless of format. The birth of NoSQL databases provided the ability to store data that is often non-relational, doesn’t require rigor or schema and is extremely portable. NoSQL databases are well- suited for handling big data.

Data modeling is therefore more necessary than ever before when dealing with non-relational, portable data because we need to know what data we have, where it is, and which systems use it.

The Imperative for Data Architecture and Enterprise Architecture

The location and usage of data are key facets of EA. Without the context of locations, people, applications and technology, data has no true meaning.

For example, an “order” could be viewed one way by the sales department and another way to the accounting department. We have to know if we are dealing with a sales order from an external customer or an order placed by our organization to the supply chain for raw goods and materials.

Enterprise architecture tools can be leveraged to manage such processes.

Organizations using enterprise architecture tools such as erwin Evolve can  synergize EA with wider data governance and management efforts. That means a clear and full picture of the whole data lifecycle in context, so that the intersections between data and the organization’s assets is clear.

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

Enterprise architecture review

Categories
Enterprise Architecture erwin Expert Blog

What Is an Enterprise Architecture Roadmap?

Having an enterprise architecture roadmap is essential in modern business. Without it, understanding the current and desired future state can be difficult.

An enterprise architecture roadmap does not have to be in contrast with efforts to promote an agile enterprise architecture. The focus of innovation and agile EA is to increase the agility of the business for digital transformation.

So it’s essential that an organization understands where it will be at any given period of time, so it’s better prepared to deal with disruption.

To keep pace with the speed of innovation and time to market, organizations need the ability to change quickly – and enterprise architecture roadmaps are a critical tool to view how complex or what the impact of the change is or will be.

Roadmaps in Enterprise Architecture

The idea of a roadmap isn’t exclusive to EA, and enterprise architects are far from the first to adopt them.

That said, the nature of roadmaps significantly compliment the way we articulate an organization’s EA. That’s because EA concepts provide a blueprint of the organization, and many aspects of these concepts can be described with a time dimension.

The time dimension can be used to either display a milestone date at which something is expected to happen, or a date range within which something will take place.

Roadmaps as “Views”

In EA, “views” refer to the different ways to represent an enterprise architecture, while keeping a consistent underlying model – similar to how one might represent the data from an excel table using a pie chart, bar chart or line graph.

The representations can offer different perspectives and/or insight that different parties may find of interest.

This enables enterprise architects to represent the information related to the enterprise architecture, according to stakeholder needs.

So just like a diagram is one view of an architecture model, so is a roadmap – offering a time-based perspective.

A roadmap is usually defined as a view for a specific time period (e.g., one year or the next three months).

Roadmaps may be dynamic and reflect the state of the concept at any moment in time in real-time, or they may be static and show how a set of concepts looked at any moment in time.

Many concepts can have multiple time attributes that represent different time properties.

In enterprise architecture, an application component may have a set of lifecycle times that are associated with it such as ’live’ or ‘sunset.’

Time attributes may simply be a single date such as a milestone or be a time period between two dates.

A roadmap view can consist of lanes. The lanes will show any theme or category for a set of concepts. A roadmap may be divided up to show different types of concepts on one roadmap.

For example, it may be useful to show work package duration and the anticipated idea implementation dates so we can see if our plans are on track.

Time usually flows from left to right on a roadmap diagram.

Example of an Enterprise Architecture Roadmap

The image below is an example showing different time properties for application components.

Enterprise Architecture Roadmap Views

As we can see, we have two lanes, live and sunset. These are themes that we may well be interested in.

We are showing on a single roadmap view both application components (CRM, SafeLogistics, SurveyTool) and a business capability (IT Offshoring).

We can show application components with the live date attribute in the live lane.

We can also view the business capability but with a sunset time period. The time period is between two dates.

In this example, we can see how a roadmap can be used to demonstrate date ranges.

The roadmap is an indication that it takes a much longer time to phase out a business capability. The time it takes to phase out a business capability is important to understand for a number of reasons.

For example, it might be important to know which resources and how many (if any) will be tied up during the process. What has to happen to the current enterprise architecture in order for said capability to be phased out efficiently?

“What-If” and Future Scenarios

Roadmaps provide a time-based view of a model. A time-based view of your concepts is essential for ‘what if’ analysis and planning future scenarios.

In different scenarios, the same set of concepts may have a different time visualization based on different time attributes.

Many organizations will have the concept of a lifecycle. It’s important for companies to adopt a set of lifecycle states that have the same meaning across their stakeholders. For example, sunset or end of life but not both.

As roadmaps are always subject to change and are extremely volatile, then roadmap views should be generated automatically from the model. There should be little reason to create roadmaps without a model. They become extremely difficult to maintain and view in different ways later on.

Organizations using erwin Evolve can take advantage of enterprise architecture roadmaps and views in a collaborative enabling, user friendly enterprise architecture tool.

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

enterprise architecture business process

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

Enterprise Architecture Tools – Getting Started

Many organizations start an enterprise architecture practice without a specialized enterprise architecture tool.

Instead, they rely on a blend of spreadsheets, Visio diagrams, PowerPoint files and the like.

Under normal circumstances, this approach is difficult. In times of rapid change or crisis, it isn’t viable.

Four Compelling Reasons for An Enterprise Architecture Tool

Enterprise architecture (EA) provides comprehensive documentation of systems, applications, people and processes.

Prior research we conducted reveals four key drivers in the decision to adopt a dedicated enterprise architecture tool:

1) Delay Increases Difficulty.

The use of Visio, MS Office files and even with a framework like ArchiMate is a recipe for anarchy. By getting into an enterprise architecture tool early, you minimize the hurdle of moving a lot of unstructured files and disconnected diagrams to a new repository.

Rather than procrastinate in adopting an enterprise architecture tool, choose a reliable, scalable one now to eliminate the administrative hassle of keeping up with disconnected data and diagrams.

2) Are We Too Dependent on Individuals and Keeping Their Files?

Some EA practices collapse when key people change roles or leave the organization. Who last updated our PPT
for capability X? Where is the previous version of this Visio diagram?

Why does this application have three names, depending on where I look? Are we following the same model and framework, or is each team member re-inventing the wheel? Is there an easier way to collaborate?

If any of these questions sound familiar, an enterprise architecture tool is the answer. With it, your EA practice will be able to survive inevitable staffing changes and you won’t be dependendent on an individual who might become a bottleneck or a risk. You also can eliminate the scramble to keep files and tasks lists in sync.

Enterprise architecture tool

3) File-Based EA Is Not Mature, Sustainable or Scalable.

With a tool that can be updated and changed easily, you can effortlessly scale your EA activities by adding new fields, using new diagrams, etc.

For example, you could decide to slowly start using more and more of a standard enterprise architecture framework by activating different aspects of the tool over time – something incredibly difficult to do with mismatched files.

Stop running next to the bike. Get on it instead.

4) Do I Want to Be the EA Librarian or a Well-Regarded Expert?

EA experts are valuable, so their time shouldn’t be spent correcting data errors in spreadsheets, generating PowerPoint files, or manually syncing up your latest Visio file with yet another spreadsheet.

Enterprise architects should be free to focus on revealing hidden relationships, redundancies and impact analyses. In addition, they need to be able to spot opportunities, presenting roadmaps and advising management about ways to manage innovation.

With an actual enterprise architecture tool, all relevant artifacts and supporting data are accessible in a central repository. And you know what was updated and when. Generate reports on the fly in minutes, not hours or days. Combine information from Kanbans, pivot tables, diagrams and roadmaps, adding your comments and circulating to others for their input.

The Increasing Importance of Collaborative Enterprise Architecture

In addition to its traditional role of IT governance, EA has become increasingly relevant to the wider business. In fact, Gartner says EA is becoming a “form of internal management consulting” because it provides relevant, timely insights management needs to make decisions.

While basic visualization tools and spreadsheets can and have been used, they are limited.

Generic solutions require makeshift collaborative efforts, like sharing PDF files and notes via email. When working remotely, this approach causes significant bottlenecks.

Even before the Covid-19 crisis, this sort of collaboration was becoming more difficult, as an increasing number of organizations become decentralized.

So the collaboration required to methodically and continuously measure and maintain models, frameworks and concepts as they evolve, was hindered.

That’s why enterprise architecture management is more strategic and impactful when powered by technology to centrally document and visualize EA artifacts for better decision-making, which is crucial right now.

erwin Evolve is purpose-built for strategic planning, what-if scenarios, and as-is/to-be modeling and its associated impacts.

Collaboration features are built into the tool enabling IT and business stakeholders to create, edit and collaborate on diagrams through a user-friendly interface.

With erwin Evolve, organizations can encourage the wider business to easily participate in EA/BP modeling, planning, design and deployment for a more complete perspective.

It also provides a central repository of key processes, the systems that support them, and the business continuity plans for every working environment so employees have access to the knowledge they need to operate in a clear and defined way under normal circumstances or times of crisis.

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

Covid-19 business resources