Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Posts Tagged ‘Systems Architecture’

ArchiMate : Its Time Has Come ?

Posted by snair007 on August 3, 2008

Proper representation of Enterprise Architecture has always been quite a challenge. Many times the sheer scope of the canvas required can be the problem, but most of the times it is the question of a proper style and standard of representation that poses issues to the IT architects. While Enterprise Reference Models (TRM or ARM) are normally pulled together as simple “box of boxes”, the lower level representations are vulnerable to subjectivity unless a firm modeling framework has been implemented and governed by the architecture board that controls the IT architecture of the enterprise.

And even if you have the standards and guidelines in place, there are still chances of unwished-for scenarios like a powerful senior leader of the enterprise caring to see things in a way he would actually understand it. Important though it is, chances are high that such short-circuiting of standards would be carried forward or be reflected in subsequent architecture artifacts. Why senior leader, – any ‘consumer’ of the artifact can challenge representation for better understandability. The preparation of models that convey the right meaning to right people without compromising across-the-board consistency and uniformity can be tough.

Challenges in Architecture Representations

Depending on the size of the organization or the authority enjoyed by the architecture board in the enterprise, the tools being used to capture and manage architecture models in an enterprise can be anything from MS PowerPoint and MS Visio to feature-laden, metadata-driven tools like Rational Suit and Telelogic System Architect. However, even the representations produced by or controlled within  very powerful, industry leading tools don’t guarantee ‘universal acceptance’ across the enterprise-wide stakeholders for reasons  ranging from complexity of the model ,  lack of features supporting a certain requisite degree of abstraction or more simply, the comfort-level of in-house managerial, architectural and development staff.

Then comes the question of standards. Most MDA (Model-Driven Architecture) complied standards like UML, MOF, XMI are really meta-frameworks meant to drive software design as in SDLC, and not meant for enterprise architecture. They are obviously no substitutes for a representation standard with enough flexibility and abstractive possibilities that EA demands.

There are also standards for visual representation of certain architecture dimensions, like BPMN and IDEF1X .But they, again, are specialized at handling respective information domains like process or data. The methods that IDEF proposes are quite comprehensive in that respect – that covers everything from standards for User interface (IDEF8) to Implementation Architecture (IDEF10) and Data(IDEF1X ) to Process (IDEF3). But they are not still really enough for Enterprise Architecture. Here is why: We simply need an Integrated View of architecture. It is easier said than done, as enterprise IT architecture addresses a different problem at a different level of abstraction than what the above models attempt. But then, when needed there has be a flexibility to go further level down in terms of details covered in the model

Let us take a quick-and-dirty stock of the requirement for EA modeling standard:

·          It should provide a comprehensive modeling framework

·          It should support an integrated (end-to-end) architecture view

·          It should be easily scalable and maintainable.

·          It should be precise and accurate

·          It should be tool-independent and conceptually portable.

·          It should be simple enough to develop and maintain.

·          It should provide representation framework for different types of enterprise architecture domains, and should support inter-domain relationships

·          It should use standard symbols for concepts and relationships, but should also communicate the underlying idea nearly intuitively to stakeholders

·          It should be capable to support major architecture life- cycle frameworks (such as TOGAF, Zachman)

Is there no silver bullet that satisfies all of these ? As usual, we tempt to say ‘nay – there can’t be‘. But there is something shining out there – let’s have a look: oh – is it not ArchiMate ?!

What is ArchiMate?

ArchiMate is a visual language to represent end-to-end enterprise architecture in terms of business processes, applications and infrastructure(technology) . It provides a consistent framework for designing multiple architecture domains and relationships among them. An integrated representation approach, ArchiMate equips the IT architects with a powerful modeling standard for representing, communicating and analyzing enterprise architecture. Like any effective modeling language should ideally be doing, ArchiMate helps evaluate the impact of changes within multiple architecture  domains and to communicate them effectively and with ease.

If you are interested in a little history, ArchiMate was a 30 months project undertaken and managed by Telematica Institute, which is essentially an international consortium of companies and several social / knowledge organizations. The project took 35 man years, and its approximate cost of 4 million euros was collectively funded by Dutch government and business partners like ABN AMRO and CWI. With due focus on the relationship between business and IT architectures, the project managed to come up with a comprehensive language for describing architecture models with precision to enable IT architecture designing solutions to standardize their techniques and offerings for effective visualization and analysis.

It is as much important to know what ArchiMate is not as to understand what it really is. ArchiMate is not software development meta language like UML, and it does not support representations in that level granularity. It is also not, like Zachman or TOGAF, an all-encompassing collection of architecture methods that can serve as a framework for the enterprise architecture to function within – its role is limited in enabling the visualization and analytical problem(s) associated with standard architecture frameworks.

In no man’s land: Positioning ArchiMate

Now, the beauty of ArchiMate is that, though it is not UML and not TOGAF, it can seamlessly correspond and relate to either of this as and when required.

Take UML as an example. ArchiMate modeling framework can accommodate most of the UML view-points. More specifically, the three composite domains (or layers)  that ArchiMate supports – business, application and technology – have a direct correspondence with three major UML diagrams – Class Diagram, Component Diagram and Deployment Diagram respectively. UML’s versions of information modeling are meant to address much finer levels of details, while ArchiMate can act as an abstract modeling framework for UML. It can also be used to meaningfully combine multiple UML views into one, thereby making use of ArchiMate as a more intuitive and self- explanatory representation working on top of the concepts captured and depicted using UML, so as to be able to present them before the stakeholders who are less familiar to Unified Modeling standards. Telematica Institute provides a detailed profiling of UML for ArchiMate in their website.

Though the nature of parallelism varies significantly, a similar statement can be made in case of TOGAF as well. While UML can be abstracted using ArchiMate, TOGAF can be typified with it. There is very high degree of similarity between TOGAF views and ArchiMate domain viewpoints in certain areas. TOGAF’s “Business Architecture” component can be visualized with ArchiMate’s business viewpoint concepts, “Information System Architecture” with application concepts and “Technology architecture” with the concepts of infrastructure concepts in ArchiMate.

There are definite ‘impendence mismatches’ between some of the TOGAF viewpoints and those of ArchiMate  due to the fundamental disparities in the roles each is supposed to play in Enterprise Architecture. TOGAF is meta-strategic blueprint for EA and ArchiMate is rather concerned about more “grounded” implementation aspects.

 

Dissecting the Dissection Box

 A complete coverage of ArchiMate’s taxonomical /ontological aspects is out of scope of this write-up. But let’s have a very quick overview to see as to what ArchiMate typically offers to an enterprise architect:

The composite view prepared using ArchiMate has 3 Layers : Business, Application and Technology. Each layer is self- contained despite being a component of the integrated model. Each layer caters to one or more architecture domains.

The Business Layer talks about how the business processes, services, functions and events related to each other and with the associated individuals and business units. This layer is defined to be consisting of Information, Product, Process and Organization domains.

In the Application Layer , the software applications that support the components in the business Layer, along with the information processed by these applications are described. This layer is defined to be consisting of Application and data domains.

The Technology Layer deals with the hardware and communication infrastructure needed to support applications specified in the Application Layer. This layer is defined to be consisting of  Technical Infrastructure domain.

Each layer contains multiple component entities called Structural Aspects or simply “structures”. Structures are key to interpreting the layer as well the integrated model at length. The answers to the question of “what do the structures do? “ are embodied by another set of entities called  Behavior Aspects, and those of the question with/by using what? “ , by a third type of entities called Information Aspects ( ArchiMate calls all these entities as simply “concepts”).

 

For More details, visit http://www.archimate.org/

 

Illustration

Here is a composite (integrated) architecture of the IT-setup in a fictional hospital – created using Archimate concepts. The topmost layer is an overview of the way the hospital functions. The one beneath that is the application layer that talks of the major application components that enables the business , along with their inter-relationships. The bottom-most one is the technology/infrastructure framework that hosts the applications of the hospital. Please bear in mind that more than the accuracy, the focus of this representation is on showcasing the potentiality of ArchiMate as an EA tool.

Click on the graphic and zoom it to view in full-size

 

Wrap-up Comments

The Open Group  (the gods of TOGAF)  has taken over the maintenance and control of ArchiMate couple of months back, and this is a very happy event for genuine lovers of the ArchiMate way of doing things (like me). I always used to wonder why the acceptance (even the awareness, for that matter) of ArchiMate is so flimsy, which should have hardly been the case with a standard of this flexibility, simplicity, comprehensibility and ubiquity (well – you can use virtually any drawing tool to pull together an ArchiMate diagram).  I earnestly hope it will soon be possible for IT architects to communicate their models developed in ArchiMate without using even a legend, to almost everyone within and outside their enterprises. ArchiMate does have that potential.

Posted in ArchiMate, Architecture Process, Data Integration, Enterprise Architecture, IT Architecture, Standards and Frameworks | Tagged: , , , , , , , , , , | 1 Comment »

Integration Methodologies: Melting Frontiers Or Age of Divergence ?

Posted by snair007 on July 18, 2008

Part1 : The Integration Big League

Integration is pretty much what IT architecture is all about. Once we get rid of the ‘fat’  from this area and get to the core of affairs, all that matters is the way components ( data,application,technological ) are fastened together. No wonder Enterprise IT Architecture and Systems Integration were used interchangeably up until a close past.

But then there are a huge lot of methods out there, the purpose of which would rather seem to confuse than to assist. But I am sure there can be no argument as to which of them are most significant – Enterprise Application Integration (EAI) and Enterprise Data Integration (EDI). As a term, EAI has proven to be monumentally more significant than EDI, but when it comes to the activities that either of them deals with, the disparity vaporizes.

In an Enterprise Architecture evolution context, where would they stand tomorrow as two approaches of integration? In a time and age when ‘components’ are made with integration in mind, how relevant (and possible) is it to retain their distinct identity? Are they heading for convergence? If so, which of the two would potentially supercede another (if at all)? Which other integration methods would get encapsulated in either of these two?

Loads of great questions, and let’s not wait to hash them out.

Egg is not the mother of Chicken, or is it?

All serious Enterprise Architecture practicians might’ve noticed how EAI and EDI are often used in affiliation with one another, if not in place of one another. But if we try to ignore this phenomenon as yet another industry misnomer, we need to be careful. I have come across many research papers and books making contradicting remarks when EDI and EAI are referred in context with each other. Some say EDI activities and tools are a part of EAI framework; others speak something quite the opposite. Still others argue that there is not much difference anyway.

And they can all be right, too!

For the time, though, let me jot down my understanding of the most accepted distinctionsbetween EAI and EDI, before dissecting each of them too much:

·          EDI focuses on unifying enterprise data views; EAI enables unifying business processes by blending applications’ capabilities.

·          EDI  is data-centric; EAI is ‘message’ centric.

·          EDI deals with high-volume data movements; data movements in EAI is normally limited to real- time/near real-time data ‘propagation’

·          The technologies used for typical EDI operations are different from those of EAI

·          EAI is normally defined to be integration of data with application or application with application; EDI is to do with data to data integration.

·          In general, data extraction is a ‘pull’ activity in EDI and in EAI; it is a ‘push’ one.

·          Data Integration may not radically alter the systems architecture of an enterprise, but Applications Integration does.

·          At one level down, the frequently talked about sub- types of EDI (EII,MDM,ETL etc) are significantly different from typical activities surrounding EAI

·          EAI can start right from the component development (by ensuring compatibility), whereas EDI is almost always an implementation/interfacing activity.

·          There are more standards, guidelines and protocols to be followed to realize EAI than in the case of EDI. Many EDI efforts can be ad-hoc and tactical.

Sigh! There are quite a few, right?

But as I posited, these ‘differences’ haven’t seemed to restrain many experts from bracketing either of them under the other. Some believe EAI is a part of EDI just like EII,ETL and Data Federation. There are other schools of though that sees no reason why EDI is not a part of EAI framework, which according to them, is immense and flexible enough to accommodate that and much more.

These chickens and eggs!

Let the argument go on; we shall go back to tackle some more important questions by taking a nigher look at each of them.

Implicitly implicit

Interestingly (and quite thankfully), there’s been a clear pattern in the way EAI technologies have evolved overtime. It is fair to say that the definition of EAI has also evolved with them. But then, arguments in favor of placing EDI under the EAI umbralla have been there in all elementary definitions of EAI. Here is how Gartner group defines EAI:

            unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.” (  a clear indication that we can regard           EDI as a subset of operations and framework that EAI offers.)

But the moment we see something like “business process” in its definition, EAI gets much more than a set of application or data components technically welded together. Linking business processes demands a well- orchestrated, business-centric approach.In other words, EAI is the technical consolidation of application silos in accordance with a set of business rules,to satisfy a set of business requirements.

An interesting aspect of EAI is that it can give rise to a set of new functionalities that the component applications wouldn’t provide in isolation. But mind you – these ‘generated functionalities’ are not‘technical accidents’ of EAI, but a result of well thought-out and estimated efforts.But both the expectations as well as the methods around this area have been varying over the years.

Wing and Venky (Enterprise Architecture and Integration,2007) give an interesting picture of how the focus of applications integration efforts have shifted over time – from one of technical to that of business.

They accurately points out that

            “The perception of integration has therefore shifted over time from tactical, low-business-value technical plumbing to a strategic and high-value enabler for     achieving business competitiveness.”

And the roadmap they present has a picture of EAI transmuting from “technical plumbing” to business-enabling frameworks generation.The focus areas making their appearances in the chronological order are systems integration, real-time integration, ERP Integration, Web Integration, Supply chain management, e-business integration,CRM, B2B Commerce and finally – collaborative commerce.

So, the future of integration is decided by business trends and paradigms rather than technological advances in data/message propagation. What does it mean to the question of addressing EAI and EDI as distinct integration streams? Answer seems quite obvious at first glance, now that we have seen the diminishing importance of integration methodologies in a rather business-centric integration environment. But is that truly the case?

To analyse that further, we must have to take a look at the types of integrations falling under each of EAI and EDI.

Let me encapsulate major EDI and EAI categories in two tables :

           

Table-1 : EDI Categories
  EDI Type  What is it ?
 
1 EII

Enterprise Information Integration

  • Multiple DBs, single virtual view
  • Fedarated approach
  • Holistic  Business View
  • Need-driven query redirection
  • “Divide-and-conquer” approach to execute queries. 

 

 

2 MDM

Master Data Management    

  • Multiple business components, single virtual ‘view’.
  • Focus on conformance with “Reference Data”
  • Focus on business consistency
  • Similar to CDI in many ways
  • Depends on a predefined / accepted “business semantics”  
  •  

3 ETL

Extract, Transform and Load

  • Synonymous with Data Warehouses
  • Normally batch- oriented
  • Differed data transfer
  • Normally based on “Pull” extracts
  • Normally uses an intermediate “staging area” for preparation and transformation
  • asynchronous
  • centralized hosting
4 RT-ETL

Real Time ETL

  • ETL process done in real-time or near real time
  • Data Propagation rather than bulk- transfer; similar to EAI
  • Normally based on “push” methods
  • “semi-synchronous”
  • centralized hosting
5 EDR 

Enterprise Data Replication

  • Replication of partial or full database
  • Rarely used as an integration solution; normally used for back-up and duplication
  • Normally use DB- triggers / transaction logs
  • CDC and Data propagation are used   
  •  

6 ECM

Enterprise Content Management

  •  Best suited for integrating data “as-is” / unstructured
  • Used for integration/consolidation of documents, web contents and rich media.
  •  ECM Products normally use a Content Management engine on top of  Data Store
7 EAI (We will see this in detail below)
8 CDI Customer Data Integration
9 CDC

Change Data Capture

  • Not so much of a type of EDI as a technique.
  • Publish-Subscribe mechanism
  •  Normally used for near real-time propagation purposes  

     

  

Table-2 : EAI Categories
  EAI Type  What is it ?
 
1 EDI

(We have seen this in detail)

  •  Integration at data level
  • Whitebox or Blackbox approach.
  • All EDI methods come under this category ( as seen above )
2

Functional Integration (FI)

-AND-

Process Integration (BPI+)

  • Integration at processes and data manipulation / interpretation rules level.
  • “Tight” application-to-application integration
  • Approach can be White / Blackbox
  • Used when presentation integration is inadequate
  • Normally wses any of the following technologies :
Message Oriented Middleware (MOM): integration through messages exchanges     

 Configurations : message queuing and message passing.

Examples : IBM’s MQSeries and Talarian’s Smart Sockets.

Distributed object technology:  Integration through application of object- oriented concepts t o middleware.

Configuration : Software components are made into objects which is then can be accessed by other applications across a network through the object interfaces.

Example : CORBA, MS COM+, J2EE,DCOM,RMI

 Transaction processing monitors (TPMs):   Integration through preserving integrity of distributed information resources (databases, files, MQs).

Configuration :To impliment distributed transaction processing support concepts like two-phase commit.  

 Example : BEA Tuxedo,web services 

 

 

3

Presentation Integration (PI)

-OR-

IUI (User Interface Integration)

  • Integration at applications’ prsentation /UI level
  • Whitebox appoach
  • Improved , Integrated access
  • Integrated user interface management(e.g validation, error handling)
4

Application Interfacing

  • Out-of-the-box Integration
  • Implemented with specializedAPIs, connectors or other forms of interfaces to access application components.
5 BPI

 Improved Functional Integration

  • Blackbox Appoach
  • Normally uses advanced middleware solutions like message brokers
  • Standardized and controlled the flow of information with a bus / hub-and- spoke framework.  

 *black box integration approach hides internal complexities of the application or database. White box approach does it the other way around.

 Next : Part2 : Convergence and Convenience

 

Posted in Data Integration, Enterprise Application Integration, Enterprise Architecture, IT Architecture | Tagged: , , , , , , , , , , , , , , , , | 1 Comment »