Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Posts Tagged ‘Architecture Governance’

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 »

Alternative Architectures : Role of Practicable Scenarios

Posted by snair007 on July 9, 2008

 

Agility Requirements: The Groundwork of Agile Architecture – Part II

 

 

Agility and ‘Range of Change’

The greatest benefit of keeping a set of ‘hypothetical’ requirements is to be able to measure what can be called “Range of Change” of the architecture. This is a positive offshoot of being proactive to changes, and this helps define the floor and ceiling of the IT architecture evolution in an organization for a specific period of time (the period during which the current architecture is valid). Range Of Change can not only drive agility, it could well be used as a crystal ball for forecasting cost and resource demands in co- ordination with company’s IT roadmap. This keeps off many ‘surprises’ and would be a great tool for CIOs/CTOs/PMO as well as Enterprise Architects.

This translates into a closer alignment of IT Roadmap with economic projections of the company. The closer the alignment, the more pragmatically agile the architecture will be. This is a refreshing answer to an interesting question: “OK – we have an architecture that is agile. Architecture that is responsive to change. But how can we convince the stakeholders that our response to the change is the best response to the change in economic terms? We believe that the interfaces defined, coupling of components, and many other agility factors in our solution are optimal and proper, but how to make a strong case of it?”.

Knowing the Range Of Change is the answer. Once you have the scenarios cut out to present to the concerned parties, you can speak with clarity and with figures for your solution. The stakeholders can anticipate how high and low the cost can really vary with a change, and they can’t ever be ‘unpleasantly surprised’ when they hear about ‘cascaded investments’ that follows a change.

Let us now see how we can put Agile Requirements into practice.

Life of Agility Requirements

In the earlier part of this discussion we have seen how requirements are derived. Enterprise Architecture Agility Requirements are nothing but a collection of expected /projected/desired changes for a specific period of time in Enterprise Business- Application-Technology domains captured at right level of abstraction in the form of requirement statements.

 An Agility requirement can therefore be of one of these types: Business Agility Requirement, Application Agility Requirement, Data Agility Requirement and Technology Agility Requirement. The importance and role of these requirements are decided by the architecture domain since the applicability and the ‘point of activation’ of requirements corresponding to each domain could vary. A Business Agility Requirement would influence Application and Technology Architectures but a Technology Agility Requirement may not call for a change in the Business view.

Alternative Architectures: Building Practicable Scenarios for Agility

Let’s now see how Agility Requirements actually get translated into a rather practicable model. An Agility requirement, as we have seen, is a high level ‘potential’ requirement. So, if we prepare ‘scenarios’ applying these requirements to the actual Enterprise Architecture, we end up having multiple ‘Alternative Architectures’ – i.e., multiple hypothetical versions of Enterprise Architecture.

Here is an outline as to how the process of translating agility requirements to alternative architectures look like:

·          Pick each of the Agility Requirements in turn and subject them to a rigorous review process to evaluate the chances of the activation of the requirement (occurrence of the change) and thereby influencing in the architecture during a certain period of time in future.

·          If chances of occurrence are found to be sufficiently high, we mark it as a ‘Potential Major Change Event'(PMCE).

·          Identify in which architecture domain each requirement falls in. Identify which all architecture views would get affected by the PMCE. For example, if a PMCE is Business in nature, it can in turn alter the Application, Data and Technology views of the Enterprise architecture. Mark the views that may potentially be altered by the PMCE.

·          Each Potential Major Change Event can trigger a unique stream of”Alternative” Business- Application-Technology architecture development process. Apply each PMCE to the architecture views/representations/high-level collaterals to come up with one modified set of them corresponding to each PMCE.

What we now have is a set of “Practicable Scenarios”, which are nothing but different versions of hypothetical high-level Architecture views ( a combination of Business/Data/Technology views).This can now tell us about how the Enterprise Architecture would look like in the event of occurrence of any of PMCE. They are much similar to multiple architecture views that one would have used for brainstorming and reviews, usually at the scoping and planning phase of Architecture development process ( Don’t throw away serious Business Scenarios such as those as specified in Part-4 of TOGAF for requirement gathering/scoping etc. They can come very handy in defining Alternative Architectures).The major difference in this case, though, is that the views we now have are much more formal and in alignment with the standard architecture frameworks that have been used to represent the Enterprise Architecture.

This process is described in the graphic below:

 

 

Benefits

Now, an obvious question here would be about the cost effectiveness/ROI of this process. Developing and maintaining multiple versions of architectures may be perceived to be a significant overhead.  Of course this is more work, but it is also of lot of value.

Here is how the Enterprise eventually benefits from developing Practicable Scenarios along with Enterprise Architecture and maintaining them:

·          Team Mobilization: If we analyze potential changes and make alternative architectures at the outset, the biggest benefit is the presence of a team that is mobilized and engaged explicitly with the enterprise architecture development work. So if a significant and radical Enterprise Architecture initiative (e.g. Adopting TOGAF) is underway, the team can work on Agility Requirements and Practicable Scenarios development. (In cases of frameworks like TOGAF, Business Scenarios development is a part of development cycle. This will give additional leverage to agility efforts.

·          Context Prevalence: When an EA initiative is in full swing, the context, awareness and ‘mood’ stands to be just right for the documenting and filing alternative architectures as inputs for future changes. If this is to be done in response to a change, the whole context of the architecture has to ‘loaded’ on to the Enterprise ‘memory’ (which is largely volatile!). So do it when the sun is still shining.

·          Finer Focus: As we have seen above, the management, team, stakeholders, vendors and other parties would all be most alert and focused when a major strategic formalization of Enterprise Architecture happens rather than responding to a major change in the enterprise.

·          ‘Swiftest’ Agility: The earlier we have a blue print in hand as to what to do when a major change happens, the less will be the risk involved, and faster the response.

·          Fastest and Effective Change Communication: With predefined alternative architectures, All the stakeholders can be notified about the changes and its repercussions along with an approved and governed strategic response in a standard, presentable to the change in least possible time.

Change-Managing Alternative Architectures

The change management of architecture prepared for agility purposes is a little tricky, and is entirely upto each architecture board and organizational culture. In brief, though, we can say with certainty that changes made to Enterprise Architecture have to get reflected on the Alternative Architectures and need to be cascaded across each set. But this can be done periodically rather than event-based, to save the overhead of having the change reflected in the alternative architectures each time there are updates to EA. The justifying assumption here is that a robust EA won’t change so frequently as to make the delay between one of its changes and the update of alternative architecture can pose a serious problem. As we have seen, the trade-off is between agility and initial efforts.

Conclusion

Developing and maintaining multiple Practicable Scenarios in the form of alternative Enterprise Architecture enhance proactive nature of the architecture management in general and agility in particular. These views help the Enterprise respond to a change with swiftest and most efficient possible agility. It also helps in communicating impacts of major business and technology changes to all concerned parties with ease as and when the change gets implemented, with minimum time spent in waiting for approvals and buy-ins.

 

 

Posted in Agile Architecture, Architecture Process, Business Scenarios Mgmt, Enterprise Architecture, IT Architecture | Tagged: , , , , , , , , , , | Leave a Comment »