Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

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.

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: