Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Posts Tagged ‘TOGAF ADM’

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.

Advertisements

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

Enterprise Architecture : How Not To Miss Anything ? -Part II

Posted by snair007 on June 21, 2008

“Getting Meticulous About It…..”

EA and EA Projects – Federated Scoping

Sorry, I can’t help harping on (I tried, though) the great ‘problem of rendition’ in EA. Right from the definition through the details, there is enough room for ‘convenient interpretation’ of many terms and ideas we find in countless Enterprise Architecture standards, frameworks and guidelines. Granted – the end-to-end roadmaps like the ones offered by TOGAF ADM are jobs very well done, but confusion lingers on in some less cheerful corners of every framework. A good example would be the difference in approaches to EA and to what can be termed as EA projects.

Wait a minute – did I say EA project? What can be termed as an EA Project? Well – everything you actually do as a part of ‘conducting’ Enterprise Architecture (You heard it right – “Conducting Enterprise Architecture” are the exact words used in the definition of MODAF. Not Conducting EA project, nor Conducting EA Activity – just conducting EA. They say MODAF is a “standardized way of conducting Enterprise Architecture and…”). So an EA Project can be any activity with enough significance to alter the EA status-quo as much as much as  being any component activity of building up Enterprise Architecture or being one that is formally aligned with Enterprise Architecture governance mode,.

The last statement, however, adds an improper degree of flexibility and thus sets in motion the wheels of convenient interpretation.

Out of Governance = Out of Scope?

Can we really take into account something that is not governed by Architecture Board as a part of Enterprise Architecture? Practically – yes , because practically in all organizations, there could be activities significant enough to disturb the EA status-quo without getting adequately controlled by governing council. The process of ‘adoption’ to EA framework would only be done at a later stage as a separate activity in such cases – mostly due to pressing deadlines, cash-flow reasons or simply sheer holes in the framework.

That leads us to having a federated approach to the scoping activity too – no matter at which rung of evolution we are at in terms of EA Framework compliance. What it means to us is this: apart from having a firm traction on governed EA Activities, there is a need for considering all substantial undertakings with definite inputs and outputs happening within the enterprise to be an EA Project; the substantiality can ideally be evaluated by governing body with minimal upfront involvement.

An EA Project can thus have a management and control outside Architecture Board. As shown in the graphic, Adoption and integration of the project to EA Framework are controlled by a pre-defined adoption strategy.

EA and EA Projects

 

But how are all these important in defining scope? They are very important, as, for one, we just saw that a project can be conceived, planned, scoped, executed and managed independently and can still be considered as an EA effort. Setting up right boundaries for such an isolated effort would be the key to all right things to follow.

 

The long and short of it: Reductionism in Scoping

Think of a sprint event. Which one would you pick as of more consequence- the distance to be covered in the race or each step that is to take you till the finishing line? Like most of you, I too would say : both. Every step is as much important as the distance to be covered. Though done inadvertently and being mastered by practice, every breath taken in, every muscle movement and every hop has its role in deciding the winner.

No holistic framework can be sound enough when it is frail in parts. Assembly may be fantastic but a week link in the chain can spoil the show, and that is where the importance of federation lies. In both the phases of scoping and planning an EA Project, the architect (an individual or a body) should be conscious of the Enterprise Significance of its outcome.

This gives a whole new importance to the scoping activity. Here we are not only concerned with scoping of the implementation of EA as a framework, but also of individual project scope in context with EA. So, the scope of the project should be defined as the scope of the business, application and technology areas of the enterprise as a whole that will be impacted by the project as well as those that constitute the project in isolation. This activity can prove to be providing great inputs to planning phase.

 

There are more to “TOGAF dimensions”

Back to the question of ‘meta’ scoping. What should we expect out of scoping exercise? TOGAF talks about 4 different dimensions ( details to be captured/ defined as a part of scoping exercise) : Scope of the Enterprise, Scope of Domains, Scope of Details, Scope of Time (not in the exact words used by The Open Group- refer TOGAF 8.1 for details ).

But are they enough?

Most of us who have ever even tried our hands on an Enterprise-Wide projects would not probably defer when I venture to say they are not all. There are some 4 more dimensions that I can think of:

Scope of Inputs:  A finite line should be drawn to mark the boundaries of information (required + available) concerning the effort. Identifying how much information would be open and/or available as inputs to the architecture effort is vital for successful execution of an EA Project . There can be numerous constraints for the Architecture Body in gathering information related to the project – like security, availability, time considerations and accessibility. On top of it, this effort should address the need of distinguish between available information and required information.

Scope of Compliance: Many Enterprise Architecture efforts are “cross-standard”. For example, while the actual development process of the architecture is being carried out in alignment with TOGAF, the security aspects of the enterprise may need to comply with SOX even as the implementation is to be carried out in an environment that follows ITIL-way of functioning. A ‘matrix of accord’ needs to be in place at the scoping phase of the project in order to meet the standards set by a multitude of standards that may or may not have requirements at variance with one another ( there should not be any, ideally).  

Scope of Usage: This is a highly overlooked factor, especially in Federated Architecture environments. As I mentioned in the previous part of my Thoughts, the effort here is to systematically capture answers to the questions like who is going to take up the architecture from the point where you leave, what will they be doing with the deliverable and whether it is development-facing or the business-facing or both.

Scope of Approval: Not everything is to be approved by everybody. Review and approval of the Enterprise Business Model should be limited to the business reps, whereas Application and Technology Models should follow a different/other review stream. I don’t very much buy in to the idea that this should be a part of defining roles and responsibilities (under planning) and not scoping, for this activity is more to do with defining boundaries of ‘jurisdiction’ rather than assigning work.

Posted in Architecture Process, Enterprise Architecture, IT Architecture | Tagged: , , , , , , , , , , | 1 Comment »