Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Posts Tagged ‘Scoping’

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 »

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 »

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

Posted by snair007 on June 17, 2008

Scoping Problem in EA

In EA , Enterprise comes before Architecture

We know our problem: not many of us get to try our hand on an across- the- board Enterprise Architecture (EA) . But then EA can also be what you like to call EA. The nature and size of architectural collateral could also vary significantly – may be it is just that cute little end-to-end view that your put together to sell your new idea to your economic patrons. Or may be it is that dreadfully large documentation that does a bible for the implementation team. EA, we should say, is one of the most debatable (flexible, for the positive you) terms of the industry. After all, you know how TOGAF’s introduction defines Enterprise:

A good definition of “enterprise” in […] context is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

And Architecture:

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”.

So a simple fusion of above statements should be good enough a definition of EA.  But frankly, I am not one too impressed. An enterprise is an enterprise. The intuitive image of something holistic that pops up in your mind should be boundlessly more satisfactory than any definition. – the big picture, that is , if not the whole picture. Architecture is big picture. EA is a big picture of a big thing. So, let me try to make a contingent statement on my own right here.

Enterprise architecture of a business/ technological entity/domain “x” is the representation at a pre-defined degree of detail of the way “x” has been/is being/will be rolled out in the smallest possible technologically sovereign organizational entity that can be termed ‘enterprise’ in the purview of the project or program or scheme or system for which the architecture of x is deemed relevant.

Good – though I qualify it to be contingent, it should not be that bad a definition. Well, those who really want to hear a definition for Enterprise Architecture bigger than ‘just enterprise-wide IT architecture’ wouldn’t possibly settle for anything less than something with logical precision such as that one. After all, people do like it when the fence around fluidity is put up as firmly as possible.

But that opens up more problems. Among many, one stands out as the most fundamental question to be answered: How to scope anything that is enterprise- wide? Or at the very least, how to approach the scoping problem?

Who scopes the scope?

An important yet often overlooked sphere of scoping exercise is the “meta-scoping” or scope-of-scoping part. At best, we would get too busy in answering the Zachman interrogative model of What-How-Where-Who-When-Why religiously, only to find ourselves overwhelmed even before the gun goes off. In fact, what we have to essentially do at this point is to be very precise: the scope elements should be captured in words rather than sentences, tables rather than documents or “boxes-of-abstraction” rather than full-blown models. We will get plenty of time before we elaborate on any piece of elementary scoping information, as the key activity in the scoping phase is not done by the architect but the stakeholders and approvers. And this key activity is review and approval! Anyone who thinks otherwise is dealing with a dangerous recipe that has enough potential to perpetuate the burden of redundancy or irrelevance of one or more scope element throughout the life-cycle of an enterprise project.

 

An architect’s role in the scoping phase for the very first iteration is more of a scribe than a technologist, and rightly so. This is the most objective of all architectural activities and any drive to push in a lot of innovation at this part of affairs would only result in widening the mismatches between the expected and the delivered. And this, I believe, is pretty universal a rule for all scoping exercises.

 

Even while getting iterative with the scope at hand at a later stage, you essentially keep sharpening the scope, rather than elaborating or expanding it. Shrinking or expanding of it means business and money, and there are people out there who are far more concerned about them than you – in your capacity as a solution designer – are. Even the fine-tuning of the scope, which normally includes activities like defining / describing the scope elements should undergo rigorous reviews with business groups in order to get rid of all traces of subjectivity ( it is slightly different from discretion, though – believe me).

 

Having said all that, we should not fool ourselves by downplaying the need of systematic scoping in any Enterprise Architecture undertaking. Though there are plenty of guidelines available for scoping activity of EA within TOGAF and elsewhere, a practical approach would cut across frameworks as we are about to see.

 

Rapid Scoping

You, the architect, are there to deliver an optimum architecture in terms of comprehensibility, usability, efficiency and ROI. The fate of each of these “desirables’” would be influenced by the decisions you make in the planning and scoping phases (I like to see them as separate activities; we will talk on that in just a bit). If you are one among those fortunate or unfortunate ones who should be the master of your own actions by being able to make decision on entire  the architectural activities , the best way is to do the following upfront, before getting too much philosophical, metaphysical or even romantic with the work at hand.

Let us see how best we can start with the scoping problem. Open a text editor or your notebook and scribble (quite literally) the answers to these queries right-away as soon as you, the architect, come out of the project (of enterprise visibility) kick-off meeting:

1. What does the term “enterprise” mean to you? What do you think it means to stakeholders? Did you see a difference?

2. What domains (data/business/process/technology/organization/location/people) would your deliverables consist of?

3. Who is going to take up the architecture from the point where you leave?  

4. What will he/she/they be doing with it – will they go present it to the board-of-the-powerful or just put on the developer spikes and get going with it? That is, who is your deliverable going to face – the development crew or the business world or both?

5. Do they plan to manage /change control / govern the architecture?( only yes or no for the time – details later , just to see if what you plan to do is a proverbial “use-and-throw” architecture )

6. If there is no architectural governance in your side of the world yet, how long will the deliverable be valid? What event(s) would make the architecture invalid or needy for changes?

7. How much detailed should the deliverables be (just in terms of sheer paper space, for now) – can you afford a good 100 pages or 3 presentation slides? 

Finally-

9. What is the verification mechanism by which you can make sure what you have captured as scope, valid?

After this quick session, the answers you would end up having in front of you may not be enough to spring much surprises in your mind, but will definitely have the potential to avert undesirable future surprises.

Now it is time for systematic scoping.

 

The Classic Interrogatives – power of simplicity

To ensure comprehensiveness, the best next foot forward is to go by Zachman Framework’s first horizontal. What-How-Where-Who-When-Why (We may term this as Rigorous Interrogation Method)

is a time-tested, robust way to pursue truth about almost everything imaginable – so there can not simply be a better way for upfront scoping.

 

This time, though, we don’t go as fast as we did in Rapid Scoping phase – we do it really meticulously. But before getting into potential challenges in the activity, let’s see what questions we need to actually ask in place of just What or How or .

 

What:    List of Business Objects,

Question: Which entities constitute the business?

How:     List of Business Processes:

Question: What does the business call various collections of activities that transform the enterprise inputs into enterprise services?

Where:  List of Business Locations

Question: Where ( which geographical entities ) is business rolled out ?

Who:     List of Organizations

Question: In which organizations does the responsibility for execution of processes and services rest?

When:   List of Events

Question: What are the events to which the enterprise responds ( upon their occurrence or relative to time) ?

Why:     List of Business Goals

Question: Where can we find pointers or references to business goals, objectives, strategies, or critical success factors significant to the enterprise relative to motivation?

Posted in IT Architecture | Tagged: , , , , , | Leave a Comment »