Tag: data architecture

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

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

Very Meta … Unlocking Data’s Potential with Metadata Management Solutions

Untapped data, if mined, represents tremendous potential for your organization. While there has been a lot of talk about big data over the years, the real hero in unlocking the value of enterprise data is metadata, or the data about the data.

However, most organizations don’t use all the data they’re flooded with to reach deeper conclusions about how to drive revenue, achieve regulatory compliance or make other strategic decisions. They don’t know exactly what data they have or even where some of it is.

Quite honestly, knowing what data you have and where it lives is complicated. And to truly understand it, you need to be able to create and sustain an enterprise-wide view of and easy access to underlying metadata.

This isn’t an easy task. Organizations are dealing with numerous data types and data sources that were never designed to work together and data infrastructures that have been cobbled together over time with disparate technologies, poor documentation and with little thought for downstream integration.

As a result, the applications and initiatives that depend on a solid data infrastructure may be compromised, leading to faulty analysis and insights.

Metadata Is the Heart of Data Intelligence

A recent IDC Innovators: Data Intelligence Report says that getting answers to such questions as “where is my data, where has it been, and who has access to it” requires harnessing the power of metadata.

Metadata is generated every time data is captured at a source, accessed by users, moves through an organization, and then is profiled, cleansed, aggregated, augmented and used for analytics to guide operational or strategic decision-making.

In fact, data professionals spend 80 percent of their time looking for and preparing data and only 20 percent of their time on analysis, according to IDC.

To flip this 80/20 rule, they need an automated metadata management solution for:

• Discovering data – Identify and interrogate metadata from various data management silos.
• Harvesting data – Automate the collection of metadata from various data management silos and consolidate it into a single source.
• Structuring and deploying data sources – Connect physical metadata to specific data models, business terms, definitions and reusable design standards.
• Analyzing metadata – Understand how data relates to the business and what attributes it has.
• Mapping data flows – Identify where to integrate data and track how it moves and transforms.
• Governing data – Develop a governance model to manage standards, policies and best practices and associate them with physical assets.
• Socializing data – Empower stakeholders to see data in one place and in the context of their roles.

Addressing the Complexities of Metadata Management

The complexities of metadata management can be addressed with a strong data management strategy coupled with metadata management software to enable the data quality the business requires.

This encompasses data cataloging (integration of data sets from various sources), mapping, versioning, business rules and glossary maintenance, and metadata management (associations and lineage).

erwin has developed the only data intelligence platform that provides organizations with a complete and contextual depiction of the entire metadata landscape.

It is the only solution that can automatically harvest, transform and feed metadata from operational processes, business applications and data models into a central data catalog and then made accessible and understandable within the context of role-based views.

erwin’s ability to integrate and continuously refresh metadata from an organization’s entire data ecosystem, including business processes, enterprise architecture and data architecture, forms the foundation for enterprise-wide data discovery, literacy, governance and strategic usage.

Organizations then can take a data-driven approach to business transformation, speed to insights, and risk management.
With erwin, organizations can:

1. Deliver a trusted metadata foundation through automated metadata harvesting and cataloging
2. Standardize data management processes through a metadata-driven approach
3. Centralize data-driven projects around centralized metadata for planning and visibility
4. Accelerate data preparation and delivery through metadata-driven automation
5. Master data management platforms through metadata abstraction
6. Accelerate data literacy through contextual metadata enrichment and integration
7. Leverage a metadata repository to derive lineage, impact analysis and enable audit/oversight ability

With erwin Data Intelligence as part of the erwin EDGE platform, you know what data you have, where it is, where it’s been and how it transformed along the way, plus you can understand sensitivities and risks.

With an automated, real-time, high-quality data pipeline, enterprise stakeholders can base strategic decisions on a full inventory of reliable information.

Many of our customers are hard at work addressing metadata management challenges, and that’s why erwin was Named a Leader in Gartner’s “2019 Magic Quadrant for Metadata Management Solutions.”

Gartner Magic Quadrant Metadata Management

Categories
erwin Expert Blog

Using Strategic Data Governance to Manage GDPR/CCPA Complexity

In light of recent, high-profile data breaches, it’s past-time we re-examined strategic data governance and its role in managing regulatory requirements.

News broke earlier this week of British Airways being fined 183 million pounds – or $228 million – by the U.K. for alleged violations of the European Union’s General Data Protection Regulation (GDPR). While not the first, it is the largest penalty levied since the GDPR went into effect in May 2018.

Given this, Oppenheimer & Co. cautions:

“European regulators could accelerate the crackdown on GDPR violators, which in turn could accelerate demand for GDPR readiness. Although the CCPA [California Consumer Privacy Act, the U.S. equivalent of GDPR] will not become effective until 2020, we believe that new developments in GDPR enforcement may influence the regulatory framework of the still fluid CCPA.”

With all the advance notice and significant chatter for GDPR/CCPA,  why aren’t organizations more prepared to deal with data regulations?

In a word? Complexity.

The complexity of regulatory requirements in and of themselves is aggravated by the complexity of the business and data landscapes within most enterprises.

So it’s important to understand how to use strategic data governance to manage the complexity of regulatory compliance and other business objectives …

Designing and Operationalizing Regulatory Compliance Strategy

It’s not easy to design and deploy compliance in an environment that’s not well understood and difficult in which to maneuver. First you need to analyze and design your compliance strategy and tactics, and then you need to operationalize them.

Modern, strategic data governance, which involves both IT and the business, enables organizations to plan and document how they will discover and understand their data within context, track its physical existence and lineage, and maximize its security, quality and value. It also helps enterprises put these strategic capabilities into action by:

  • Understanding their business, technology and data architectures and their inter-relationships, aligning them with their goals and defining the people, processes and technologies required to achieve compliance.
  • Creating and automating a curated enterprise data catalog, complete with physical assets, data models, data movement, data quality and on-demand lineage.
  • Activating their metadata to drive agile data preparation and governance through integrated data glossaries and dictionaries that associate policies to enable stakeholder data literacy.

Strategic Data Governance for GDPR/CCPA

Five Steps to GDPR/CCPA Compliance

With the right technology, GDPR/CCPA compliance can be automated and accelerated in these five steps:

  1. Catalog systems

Harvest, enrich/transform and catalog data from a wide array of sources to enable any stakeholder to see the interrelationships of data assets across the organization.

  1. Govern PII “at rest”

Classify, flag and socialize the use and governance of personally identifiable information regardless of where it is stored.

  1. Govern PII “in motion”

Scan, catalog and map personally identifiable information to understand how it moves inside and outside the organization and how it changes along the way.

  1. Manage policies and rules

Govern business terminology in addition to data policies and rules, depicting relationships to physical data catalogs and the applications that use them with lineage and impact analysis views.

  1. Strengthen data security

Identify regulatory risks and guide the fortification of network and encryption security standards and policies by understanding where all personally identifiable information is stored, processed and used.

How erwin Can Help

erwin is the only software provider with a complete, metadata-driven approach to data governance through our integrated enterprise modeling and data intelligence suites. We help customers overcome their data governance challenges, with risk management and regulatory compliance being primary concerns.

However, the erwin EDGE also delivers an “enterprise data governance experience” in terms of agile innovation and business transformation – from creating new products and services to keeping customers happy to generating more revenue.

Whatever your organization’s key drivers are, a strategic data governance approach – through  business process, enterprise architecture and data modeling combined with data cataloging and data literacy – is key to success in our modern, digital world.

If you’d like to get a handle on handling your data, you can sign up for a free, one-on-one demo of erwin Data Intelligence.

For more information on GDPR/CCPA, we’ve also published a white paper on the Regulatory Rationale for Integrating Data Management and Data Governance.

GDPR White Paper

Categories
erwin Expert Blog Enterprise Architecture

Data-Driven Enterprise Architecture

It’s time to consider data-driven enterprise architecture.

The traditional approach to enterprise architecture – the analysis, design, planning and implementation of IT capabilities for the successful execution of enterprise strategy – seems to be missing something … data.

I’m not saying that enterprise architects only worry about business structure and high-level processes without regard for business needs, information requirements, data processes, and technology changes necessary to execute strategy.

But I am saying that enterprise architects should look at data, technology and strategy as a whole to develop perspectives in line with all enterprise requirements.

That’s right. When it comes to technology and governance strategies, policies and standards, data should be at the center.

Strategic Building Blocks for Data-Driven EA

The typical notion is that enterprise architects and data (and metadata) architects are in opposite corners. Therefore, most frameworks fail to address the distance.

At Avydium, we believe there’s an important middle ground where different architecture disciplines coexist, including enterprise, solution, application, data, metadata and technical architectures. This is what we call the Mezzo.

Avydium Compass Mezzo view
Figure 1 – The Avydium Compass™ Mezzo view

So we created a set of methods, frameworks and reference architectures that address all these different disciplines, strata and domains. We treat them as a set of deeply connected components, objects, concepts and principles that guide a holistic approach to vision, strategy, solutioning and implementations for clients.

For us at Avydium, we see the layers of this large and complex architecture continuum as a set of building blocks that need to work together – each supporting the others.

Avydium Compass view of enterprise architecture
Figure 2 – The Avydium Compass® view of enterprise architecture

For instance, you can’t develop a proper enterprise strategy without implementing a proper governance strategy, and you can’t have an application strategy without first building your data and metadata strategies. And they all need to support your infrastructure and technology strategies.

Where do these layers connect? With governance, which sets its fundamental components firmly on data, metadata and infrastructure. For any enterprise to make the leap from being a reactive organization to a true leader in its space, it must focus on data as the driver of that transformation.

DATA-DRIVEN BUSINESS TRANSFORMATION – USING DATA AS A STRATEGIC ASSET AND TRANSFORMATIONAL TOOL TO SUCCEED IN THE DIGITAL AGE

 

Data-Driven Enterprise Architecture and Cloud Migration

Let’s look at the example of cloud migration, which most enterprises see as a way to shorten development cycles, scale at demand, and reduce operational expenses. But as cloud migrations become more prevalent, we’re seeing more application modernization efforts fail, which should concern all of us in enterprise architecture.

The most common cause for these failures is disregarding data and metadata, omitting these catalogs from inventory efforts, part of application rationalization and portfolio consolidation that must occur prior to any application being migrated to the cloud.

Thus, key steps of application migration planning, such as data preparation, master data management and reference data management, end up being ignored with disastrous and costly ramifications. Applications fail to work together, data is integrated incorrectly causing massive duplication, and worse.

At Avydium, our data-driven enterprise architecture approach puts data and metadata at the center of cloud migration or any application modernization or digital transformation effort. That’s because we want to understand – and help clients understand – important nuances only visible at the data level, such as compliance and privacy/security risks (remember GDPR?). You want to be proactive in identifying potential issues with sensitive data so you can plan accordingly.

The one piece of advice we give most often to our clients contemplating a move to the cloud – or any application modernization effort for that matter – is take a long hard look at their applications and the associated data.

Start by understanding your business requirements and then determine your technology capabilities so you can balance the two. Then look at your data to ensure you understand what you have, where it is, how it is used and by whom. Only with answers to these questions can you plan and executive a successful move to the cloud.

Categories
erwin Expert Blog

Enterprise Architecture vs. Data Architecture vs. Business Process Architecture

Enterprise architects, Data architects, Process architects

Despite the nomenclature, enterprise architecture, data architecture and business process architecture are very different disciplines. Despite this, organizations that combine the disciplines enjoy much greater success in data management.

Both an understanding of the differences between the three and an understanding of how the three work together, has to start with understanding the disciplines individually:

What is Enterprise Architecture?

Enterprise architecture defines the structure and operation of an organization. Its desired outcome is to determine current and future objectives and translate those goals into a blueprint of IT capabilities.

A useful analogy for understanding enterprise architecture is city planning. A city planner devises the blueprint for how a city will come together, and how it will be interacted with. They need to be cognizant of regulations (zoning laws) and understand the current state of city and its infrastructure.

A good city planner means less false starts, less waste and a faster, more efficient carrying out of the project.

In this respect, a good enterprise architect is a lot like a good city planner.

What is Data Architecture?

The Data Management Body of Knowledge (DMBOK), define data architecture as  “specifications used to describe existing state, define data requirements, guide data integration, and control data assets as put forth in a data strategy.”

So data architecture involves models, policy rules or standards that govern what data is collected and how it is stored, arranged, integrated and used within an organization and its various systems. The desired outcome is enabling stakeholders to see business-critical information regardless of its source and relate to it from their unique perspectives.

There is some crossover between enterprise and data architecture. This is because data architecture is inherently an offshoot of enterprise architecture. Where enterprise architects take a holistic, enterprise-wide view in their duties, data architects tasks are much more refined, and focussed. If an enterprise architect is the city planner, then a data architect is an infrastructure specialist – think plumbers, electricians etc.

For a more in depth look into enterprise architecture vs data architecture, see: The Difference Between Data Architecture and Enterprise Architecture

What is Business Process Architecture?

Business process architecture describes an organization’s business model, strategy, goals and performance metrics.

It provides organizations with a method of representing the elements of their business and how they interact with the aim of aligning people, processes, data, technologies and applications to meet organizational objectives. With it, organizations can paint a real-world picture of how they function, including opportunities to create, improve, harmonize or eliminate processes to improve overall performance and profitability.

Enterprise, Data and Business Process Architecture in Action

A successful data-driven business combines enterprise architecture, data architecture and business process architecture. Integrating these disciplines from the ground up ensures a solid digital foundation on which to build. A strong foundation is necessary because of the amount of data businesses already have to manage. In the last two years, more data has been created than in all of humanity’s history.

And it’s still soaring. Analysts predict that by 2020, we’ll create about 1.7 megabytes of new information every second for every human being on the planet.

While it’s a lot to manage, the potential gains of becoming a data-driven enterprise are too high to ignore. Fortune 1000 companies could potentially net an additional $65 million in income with access to just 10 percent more of their data.

To effectively employ enterprise architecture, data architecture and business process architecture, it’s important to know the differences in how they operate and their desired business outcomes.Enterprise Architecture, Data Architecture and Business Process Architecture

Combining Enterprise, Data and Business Process Architecture for Better Data Management

Historically, these three disciplines have been siloed, without an inherent means of sharing information. Therefore, collaboration between the tools and relevant stakeholders has been difficult.

To truly power a data-driven business, removing these silos is paramount, so as not to limit the potential analysis your organization can carry out. Businesses that understand and adopt this approach will benefit from much better data management when it comes to the ‘3 Vs.’

They’ll be better able to cope with the massive volumes of data a data-driven business will introduce; be better equipped to handle increased velocity of data, processing data accurately and quickly in order to keep time to markets low; and be able to effectively manage data from a growing variety of different sources.

In essence, enabling collaboration between enterprise architecture, data architecture and business process architecture helps an organization manage “any data, anywhere” – or Any2. This all-encompassing view provides the potential for deeper data analysis.

However, attempting to manage all your data without all the necessary tools is like trying to read a book without all the chapters. And trying to manage data with a host of uncollaborative, disparate tools is like trying to read a story with chapters from different books. Clearly neither approach is ideal.

Unifying the disciplines as the foundation for data management provides organizations with the whole ‘data story.’

The importance of getting the whole data story should be very clear considering the aforementioned statistic – Fortune 1000 companies could potentially net an additional $65 million in income with access to just 10 percent more of their data.

Download our eBook, Solving the Enterprise Data Dilemma to learn more about data management tools, particularly enterprise architecture, data architecture and business process architecture, working in tandem.