EA - Enterprise Architecture in Action

By Murteza Salemi

Information in SOA world is often considered only within the context of specific services and processes whilst the most awaited gains and benefits of SOA investment is business information availability throughout the organization and to its partners and regulators. When an organization embarks on SOA and integrates its internal systems across LOB’s it will soon discover that there are inconsistencies in its information that was not visible before as it was hidden within various silo applications and data sources.

 SOA focuses mainly on mapping service components to business processes, and on mapping business processes to business services. However, during this process the quality of the data involved is either ignored or given low priority. Implementing and running services on top of distinct legacy systems, applications and repositories, each with their own levels of data quality and without cross-system de-duplication and cleansing, results to an SOA solution that looks great on the surface but internally hold poor data quality. How can one, for instance, implement an enterprise wide Customer Service or Product Service when parts of the customer and product data are scattered over several data sources with different levels of data consistency, and without proper data matching and de-duplication? Which data source should the service pick its data from for further processing?
Without having MDM in terms of information services in place to cater for data quality and consistency, applying service oriented architecture can make the matter worse and have unpleasant and in some cases dire consequences for an organisation. This is simply due to now having services that expose incorrect, un-trusted, duplicated and un-cleansed data that is consumed by many more consumers than when there was no SOA in place. As SOA is a strategic enterprise wide initiative, MDM needs to be considered at the same level rather than a specific project implementation for a specific line of business.

Of course it is quite possible to implement MDM without services or SOA architecture. Instead of building services to maintain and retrieve the master data, ETL (extract, transform and load) tools could be used to build the required master data management solution. Data can be standardized, validated, de-duplicated and cleansed whilst it is being pushed into an MDM underlying data model. However, the ETL job batches that implement such a solution would quickly become fairly complicated in any approach to the same level of data quality as can be achieved by a set of well-designed information services.
 In a rather simple scenario a non-SOA MDM approach might work  but it will not have the advantages of being real-time services as “information as service” would offer. Such a non-SOA solution approach will hinder the smooth integration between this solution and the rest of the enterprise business processes as otherwise it could be easily achieved by SOA approach. Capabilities such as instant updates with proper transactional (two-phased commit, XA compliant) control would not be available. Security, data visibility, and data entitlements would be hard to control if data access is done directly to the database, and so forth.

In short, MDM implemented as “information as service” will complement the goal of service orientation and push SOA to reach its full potential for an organisation. Information that is trusted and delivered in-line and in context can be an accelerator to innovation, enabling organisations to optimize their operations, reduce their risk, and discover new business opportunities. Simply by improving visibility into business operations and core business data, companies are better equipped and armed to compete effectively. Information integration through MDM solves this by giving processes, people and applications a single view of the truth. SOA enables this single view to be made accessible to the entire enterprise, ensuring that consistent governance is always in place and enforced. It also offers more flexibility to change, by insulating application changes from information changes.

Posted by Shubhankar Sumar at 2:05 PM | Permalink | Comments (0) | TrackBacks (0)

- Jerry Larivee

Yesterday I had jury duty; one of only two civic duties enumerated in the US Constitution – the other being voting (ok paying taxes might count as three, but let’s not go there).  Anyway, several hours of sitting in a court house did get me thinking about the “rules of evidence” for architecture.

A common pitfall that IT organizations fall into when trying to formalize the practice of architecture is to setup an architecture review broad (ARB) without proper foundation; specifically without setting down the rules of evidence for architecture.  In ancient times the village elders or some monarch dispensed justice without formal legal structure, but I’ve yet to see an ARB that wielded this kind of absolute authority over IT projects.

So just as modern courts are governed by rules of evidence, the ARB must define what is to be presented as part of an architecture review and what criteria is to be used to judge the fitness of what’s presented.  TOGAF™ provides a succinct description of the function of an “Architecture Board” without trying to define any strict formula for an ARB to follow.  Nor will I try.  Instead I’ll just focus on some of the basics.

Standards

A common ARB function is to ensure conformance to standards.  If the organization has not defined any standards or has failed to define standards that are relevant to the projects that the ARB will review, then this part of the review becomes little more than a debate between architects.  It may be a debate in good faith, but that’s called a design review and whereas I’m all in favor of architects reviewing each other work and giving feedback, this process generally lacks the kind of demonstrable benefits that are required to justify anything beyond the most cursory investment of resources in the ARB.

I mentioned the importance of standards being relevant.  Standards are defined because they either solve a common problem, thus saving time and resources from having to solve the same problem over and over again, or they support some other architectural objective such as security or ease of integration.  If one can’t demonstrate how either of these is the case for a project under review, then the standard is not relevant and enforcing conformance becomes a challenge.

When deciding where to start with defining standards it’s a good idea to look in three areas:

1. Look at what is in common use in the organization today.  This represents a set of successfully applied solutions to a set of known problems.  It also represents technology that is already familiar to the organization and skills sets that are already available.
2. Look at the pipeline of projects in development or under consideration.  This represents a set of problems that will need to be solved in the near future, but be sure to look for common problems, not simply interesting ones or even the hard ones.
3. Look at known architecture priorities of the organization.  E.g. improving security, enhanced analytics capabilities, or improved integration between systems.

Architecture Artifacts

A well defined set of standards is not the only requirement for a successful ARB.  Defining what has to be brought into the review is also important.  Besides allowing the project team to appropriately prepare for an architecture review it also ensures that the ARB get’s a complete and accurate picture of the project under review and solutions being proposed.

For many a project teams, an architecture review is nothing more than a hurdle to be passed with as little delay or disruption to the project plan as possible.  Thus the project team is often incentivized to game the review process, not to embrace it.  Gaming the review process is usually just a matter of presenting those aspects of the project that are most well understood and avoiding those areas that are less understood when presenting the project to the ARB.  This is only possible when the material to be presented is left up to the discretion of the project team.

Defining what architecture artifacts should be brought into a review should be based on the artifacts that are already being created as a part of the project.  The challenge here is that many an organization lacks a really well defined architecture methodology that all projects follow.  Exactly what type of artifacts should be a part of a project architecture methodology, I’ll leave for another (much longer) posting.  The key is that when defining the artifacts that should be created as part of the project and brought into the architecture review one should keep in mind what information about what aspect of the project or the proposed solution each artifacts is communicating and how each artifacts is used in future steps in the process.

Scope

The scope of the architecture review also needs to be defined.  Is it just about application architect? Does it cover data and information architecture?  Does it cover infrastructure?  For whatever scope is defined for the ARB, the appropriate standards and artifacts need to be defined.  Also the ARB needs to include subject matter experts across the full scope of the ARB.

Many organizations divide the architecture review process across multiple boards.  This separation of concerns can be useful in ensuring that each area of concern is fully addressed, but it can also provide an additional burden for the project team to have to prepare multiple reviews.  When choosing to separate concerns it is still important to have some coordinating function to ensure that all the appropriate concerns are addressed; this is often delegated to whatever general project governance process exists.

Outcomes

Posted by Jerry Larivee at 6:18 PM | Permalink | Comments (0) | TrackBacks (0)