Stakeholder support seems to be the #1 indicator of success for new Enterprise Architecture (EA) programs. I wouldn’t even attempt this without the commitment of a high-level sponsor such as the CIO. Support from other stakeholders is also crucial, but this can be cultivated over time (more typically a short time than a long time). You require broad support of the concept as well as financial backing.
Setting up metrics and measuring against them are also critical at the start of the program. Set modest goals initially and try to exceed them.
If the enterprise has a Project Management Office (PMO), then the natural synergies between the EA program and the PMO should be cultivated. The PMO should have access to all the projects in the pipeline as well as cost and risk data that is valuable to the EA. Any governance around the projects can be extended to include EA.
This is a large topic and this only scratches the surface. We will get into some more details in upcoming posts.
In this post we will cover the differences between Business Architecture and Enterprise Architecture. First, let’s start with some definitions.
The Business Architecture is a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.
Business Architecture provides multidimensional views of business capabilities, governance structures, partners, semantics, projects, value chains, processes and rules. Business architecture also serves as the basis for IT architecture alignment.
Enterprise Architecture (EA) is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.
BA and EA Contrasted
The definitions appear very similar, but the key point distinguishing the 2 is that Business Architecture is a subset of Enterprise Architecture.
EA also includes Data Architecture, Technology Architecture, and Application Architecture. Business Architecture is an important domain with in Enterprise Architecture, but it is not the only domain!
One of the major processes concerning Master Data Repositories is the handling of data exceptions. These exceptions arise when data being provided is incompatible with the MDR being loaded.
Some examples of exceptions are:
- Null data when expecting a value
- Character data when expecting numeric
- Data that does not pass a validation screen (e.g. Postal Code mask)
In a real time interface, the challenge is lessened, as an error code can be returned back and the update refused.
With batch processes, the situation can become far more complex.
Batch MDR Exception Handling Techniques
How these exceptions are handled have some very far reaching consequences. It is important that the business users understand the process that is implemented and, ideally, have the opportunity to provide input into the creation of the processes.
Some possible processes:
- Allow the “bad data” to be input into the MDR, but flag it for possible follow up
- Reject the exception data, place in a holding queue for:
- Automatic correction and/or Manual correction
- Send back to provider
- Obliteration (don’t care about this or not worth the trouble to fix)
A canonical data model is a model that is agnostic of the models of both the providers and the consumers of the data.
What does this mean?
Basically, we want the canonical database to be a “bridge” between the formats of the data that are coming in and the formats going out and not be influenced by any of these formats.
What is the advantage of a canonical data model?
The systems that provide the data will be changed, upgraded, or retired over time. The same for the consumers of the data. These events can happen in relative isolation by virtue of the canonical model.
For example, the replacement of an upstream system merely requires that the new system publish information to the canonical model in the expected format. No changes to downstream systems are required.
When are canonical models used?
Canonical models are used in the practice of Master Data Management and Application Integration.