Enterprise Architecture Demystified

Sethuraj Nair’s Enterprise Architecture Thoughts

Posts Tagged ‘Agility’

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

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

Agility Requirements: The Groundwork Of Agile Architecture – Part I

Posted by snair007 on July 6, 2008

Agility, Architecture and Agile Architecture

What a good word Agility is!  You are agile only when you are alert and adaptable, both. Hats off to the wise soul – whoever it was – that discovered its utility in ever-wavering frames of Information Technology practices. In any case, it was just a matter of time since its possible coinage before we started seeing its decisive presence in a gamut of IT methodologies and standards – Agile Programming, Agile Design, Agile Application Development and of course Agile architecture.

Why should architecture be agile? Is it advisable to see something that is to be rightly regarded as an authentic reference/blueprint of action to be as a variable in itself? Is it just about architecture change management?

Or to ask more directly- how important is the concept of agility in architecture?

One plain (and proper) definition of agility is as the ability to react to upcoming changes effectively and efficiently (Ambrose, Morello, 2004). In this sense, each architecture effort, if it is not done as a part of a fresh full life-cycle project, is meant to deliver exactly this purpose. It is so important that one can even argue we do architecture for agility rather than with agility.

Implicit and Explicit Agility

We need to know what we have and how it all add up in order to be able to assess the impact of a change so much as to know what is going to change, when, where, how and why it changes. We also need to know the architecture of our systems to know what each change will cost us in terms of money, time and effort. So to have a good architecture is the undoubtedly the first step of being agile. In other words, the greatest objective of Enterprise Architecture is to assist agility. Going by this logic, one may tend to think that Agile Enterprise Architecture is badly phrased; if not that it is an absolute oxymoron. And believe me – this is not entirely wrong. Agility is implicit in IT architecture.

But intention of this being regarded as a major EA topic is good. We normally say Agile Architecture to stress the importance of an architecture that is optimized for changes. So, while capturing the “As-Is” architecture is implicitly and arguably agility-driven, defining the ‘To-Be’ state is much more than that. In the latter case, we strive to devise an architecture that is to respond to changes ‘effectively and efficiently’, rather than to pull the current architecture together to fine-tune our understanding of the system(s) to handle potential changes ’effectively and efficiently’. We should therefore rather focus on this future-state modeling when we talk on Agile Architecture.

Focus On Agility: Agility Requirements – Foresee & Be Agile

Agility is the conceptual parent of many best-loved architecture features like dynamism, vibrancy and some most popular paradigms like SOA. They all deal with agility in their own ways. Agility is everywhere; though it is important to know how much is present where.

We have just seen how architecture can be implicitly and/or explicitly agile. But what do we normally do for making architecture agile? A good enterprise future-state architect definitely keeps the big agility factor in mind, but how often do we address agility factor upfront? Many architecture frameworks overlook considering agility in scoping and planning phases. We need to aim directly at the bull’s eye to increase the probability of striking it – we need to treat agility as the foremost success-criteria upfront for an architecture undertaking to make the implemented system agile. The first and most important step in this direction is to understand the organization’s ‘agility requirements’. When we gather architecture requirements, we normally tend to neglect the need of capturing a set of requirements under the head ‘agility requirements’. But the challenging question is how we can identify our ‘agility requirements’. How can we put down something that is uncertain and fluid? And most important of all, who is going to provide agility requirements?

We will see this in detail in later sections soon, and for the time, we only need to understand that agility as an architectural characteristic that is worth getting prime attention – expressly and systematically.

If we can actually expect changes, we would respond to them more effectively. And this simple logic makes a powerful case for gathering, organizing and representing agility requirements as one separate part of requirements collection phase of the architecture effort. Not only that it saves time, money and efforts, it also places the change in a politically and strategically favorable zone now that the change was an anticipated one. But is it about predicting changes, really? And if so it is, is it practical?

Science and Methods of Agility Requirements

Deductive Method

One way of identifying agility requirements is to understand the actual pattern of your business and technology changes. In most enterprises, there could be a significant degree of commonality across ‘System Change Events’ (SCE, if you like) happening over a period of time, due to business, ‘political’, geographic, economic and other reasons. It is possible to get considerable insights on the nature of ‘expectable’ changes by analysing changes that have been happening for a certain period of time. Presenting a full- fledged methodology for identifying the SCEs and analysing them is beyond the scope of our present discussion, though I would wish to rake up the applicability of some of the classic methods of pattern identification in this area – such as statistical approaches and data mining.

It is quite possible for a good enterprise to keep a history of their key business, application, data and technology changes, which I prefer to classify as System Changes (yes – I understand ‘system’ is a subjective term). In some cases though, the changes would be captured at a very granular level and without any proper plan to place the changes in context with each other to make it architecturally significant. The changes in Network topologies , changes in CI configurations and resources, applications patching and upgrades, adding new types of users to an application or configuration items are all System Changes but not with much use until they are rolled up to a proper higher level. Either way, with a focused and scientific approach, it is possible not only to conform these changes to a certain desired level of abstraction, but also to ‘make sense’ of this data.

So the ‘deductive method’ of agile requirement capture include mainly 2 steps :

      (1) To Prepare: To collect, organize, level-up the System Change Events in order to dress them       up for analysis.

      (2) To Analyze: To apply mathematical-statistical data mining techniques to draw    inferences that are direct inputs to Agile Requirements capture process.

 

What we look out for in an organized set of historical change records is a pattern of occurrence of various categories of changes, so as to be able to make sensible prediction and projections..

Let’s see some examples

Result of SCE analysis:

      There is a pattern in which a particular technology component ‘x’  is rolled out in a particular  geographical entity ‘y’.

The agility requirement corresponding to this finding would be something like:

      ‘To anticipate the implementation of upcoming releases or versions of ‘x’ in ‘y’.

Another One:

      ‘There are cases of recurring failures of implementing a certain strategic directive /standard ‘s’ in     certain client account ‘y’ ‘.

This translates into an Agility requirement statement that goes like:

      ‘To anticipate implementing an alternative to ‘s’ in account ‘y’ ; to keep an alternate blueprint of       implementation just for this account.’

In some cases, the ROI can be found significantly higher with specific changes, which would make way to repeat similar changes in future. Cases like this enable us to make fair, rather direct predictions.

Analysis and consultation

The most obvious method of gathering agility requirements is to do that in a requirement gather session from business representatives and stake-holders as ‘parking lot’ buy-ins. It is not recommended to get very formal with the process, though – as it may sound to be a rather speculative business. There should be enough transparency while asking for expectations. The ‘donor’ of a strategic tip-off may not be ready to own it or vouch for it , and rightly so. But it may prove to be valuable when you do agility requirements analysis.

Another important option is to seek internal or external professional assistance to do keep a tab on industry trends and developments. Agility of the enterprise is proportional to its foresight substantiated by quality trend-analysis, and the architecture responsive to the industry developments always identifies and assimilates trend data in consultation with business experts and analysts who can make quantified predictions as to which business and technology components can undergo changes in a certain period of time.

Next: Agility Requirements: The Groundwork of Agile Architecture Part-2 : Real Actions, Range of Change, Cost , resources and risk

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