+1 The problem is also that agility is about what is appropriate to a given area. Procurement doesn't need to be agile, its actually about stopping you buying stuff so what does agility give you? Finance and accounting rules change once a year (at most) so what sort of agility do you need there?
Measuring maturity makes sense, but agility is business area specific and is about appropriate cost/benefit for agility rather than agility in itself being a good thing. Steve On 19/01/2008, Michael Poulin <[EMAIL PROTECTED]> wrote: > > To me, comparison Agility Model to SOA Maturity Model, taken in the > ZapFlash, sounds a bit as apples to oranges. "Measuring agility on a scale > of 1 to 5 (as almost all maturity models do), is a pointless " indeed. I > do not know anybody who would do this. However, measuring a project agility > inside this or that Maturity Model is a regular thing. A SOA Maturity Model > ( at least, the ones I saw) always had certain definition/measurement of > service solution agility for each of the Maturity Model levels. Plus, the > higher levels usually included the lower ones. > > Thus, it is nothing wrong if a project implements agility at the level 1 > in the organisatoin which is at the 4th level of Maturity Model. First, not > all projects need the same level of maturity (as ZapFlash notice), second, > the project must have strong reasons for building for exceptional maturity > level. > > What is unclear to me is an "absolute" style of Agility Model level > comparison. That is, "Considering these Agility Measures, the fewer > degrees of freedom and variability, the less agile the system as a whole." > I think, it has to be rather relative to the "degrees of freedom" > available for particular business subject. If it is stable enough, the > "degrees > of freedom" may lead to over-enginnering. > > While I find Seven Levels of Agility a good starting point, I am afraid, > we do not have objective criteria to measure variability - when enough is > enough? This seems to be very subjective and, in some cases, dependent on > not SOA savvy decision makers (e.f., project managers). > > - Michael > > > > > > ----- Original Message ---- > From: Gervas Douglas <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, January 18, 2008 2:48:15 PM > Subject: [service-orientated-architecture] [ZapFlash] Forget Maturity > Models -- It's Time for an Agility Model > > > > [image: <SPAN id=]ZapThink" border="0"> *ZapFlash: In this Issue Jan 17, > 2008* > > > Forget Maturity Models – It's Time for an Agility Model Document ID: > ZAPFLASH-2008117 | Document Type: ZapFlash > *By: Ronald Schmelzer* > Posted: Jan. 17, 2008 > > Companies need to know where they stand. The desire to measure progress is > especially the case with regards to IT – something that many business people > regard as intangible, unpredictable, and unreliable. One way of reining in > all this uncertainty is to apply industry-wide metrics and measures to > enterprise IT projects. Using these measures, companies can ideally > determine if they are ahead of their competition and generally moving in the > right direction with regard to their IT projects. Many companies look to > certain industry-wide maturity models to fill this need. However, this is > exactly where most maturity models fall flat. > > Too often, companies flock to maturity models, such as the widely-famous > (and too-often mimicked) Capability Maturity Model Integration (CMMI), > without adequately understanding what they are meant to measure. Now, the > point of this ZapFlash is not to explain CMMI or equate CMMI and SOA > Maturity Models... they have nothing to do with each other from either > content or context perspective. However, most SOA Maturity Models try to > mimic the CMMI in structure and format without realizing that it's not > relevant. > > Many abstractly measure an organization against arbitrary measures of > maturity without factoring in an organization against others of its size, > geography, or industry. Does it make sense that IT organizations in the > retail sector should face the same rigorous discipline of IT measurement as > companies in the financial sector? Does the measure of maturity factor in > the average of all the activities in the organization, the most advanced, or > the least advanced? Does the maturity model measure the company > organization- wide, on a department-by- department basis, or on a > per-project basis? Without understanding what the maturity model measures, > it's hard to say if it truly is any real measure of maturity. > > More importantly, what is the maturity model meant to motivate? For many > companies, achieving a certain level of maturity has primarily a > marketing-only value for the end-users. Other maturity models are positioned > primarily to sell vendors' products. But scarce few are meant to advance the > state of adoption of a particular IT practice in an organization. If the > most popular maturity models fall flat here, this is even more so the case > with SOA Maturity models. As we discussed in our Quantity is No Measure of > Maturity <http://www.zapthink.com/report.html?id=ZAPFLASH-200744> and What > to Look for in a SOA Maturity > Model<http://www.zapthink.com/report.html?id=ZAPFLASH-20051031>ZapFlash, most > SOA maturity models fall into one of the three camps: > ill-defined, abstract models of maturity that are primarily based on Service > implementation rather than Service architecture, vendor-driven maturity > models that attempt to push customers through SOA infrastructure buying > decisions, and consultant-driven maturity models that attempt to push > customers through architectural exercises that have not proven to truly > advance the state of SOA. > > It's becoming clear that the industry doesn't really need a SOA maturity > model. The act of doing SOA properly in itself is an act of architectural > maturity that many companies are having trouble grasping. Companies are > trying to understand how to best apply SOA and realize the benefits against > their own stated business goals. As such, what's not needed is an abstract, > enterprise-wide, industry-wide, artificial measure of maturity that complies > with CMMI's five levels, but rather a way of measuring the state of a SOA > implementation against the fundamental goal of SOA itself: agility. > > *Introducing the Agility Model* > What ZapThink is proposing in an ideal Agility Model is a measure the > agility of a particular SOA implementation against solid measures of > flexibility. Rather than shooting to measure a project against an arbitrary > five levels of maturity, where the assumption is that the top level is the > "best", the idea is to measure the agility against the goals for the > business and that project. > > Measuring agility on a scale of 1 to 5 (as almost all maturity models do), > is a pointless exercise. Simply put, not all Service-oriented projects need > to have the same level of agility as others. Some project require deep > levels of loose coupling at perhaps all the levels we discussed in our > previous Seven Levels of Loose Coupling > ZapFlash<http://www.zapthink.com/report.html?id=ZAPFLASH-20071128>. > Other projects might not need the same amount of loose coupling since each > layer of coupling adds flexibility at the potential cost of complexity and > efficiency. Good architects know when to make Services and processes loosely > coupled enough to meet the business requirements and meta-requirements of > agility <http://zapthink.com/report.html?id=ZAPFLASH-2006824>, but not any > more so. As such, we should consider the Agility Measure to be a spectrum of > sorts, with the desired level of agility matching the business requirement. > > As such, companies should shoot for "optimal" where anything outside of > that is suboptimal. To be specific, if a business is aiming for a specific > level of agility, but the projects have been implemented in a way that has > made them more flexible then desired, it's quite possible they might have > been over-engineered. Likewise, projects that don't achieve the desired > Agility Measure are suboptimal and under-engineered. As a rule, the more > agile a system is, the more expensive it will be, so it's important for an > organization to be able to prioritize their agility requirements in order to > determine which ones they want to pay to satisfy, given budgetary and other > constraints. As such, I wouldn't recommend a corporate-wide Agility Model, > as there will be varying requirements for agility at varying times and in > different parts of the organization. > > The key question to answer in considering the Agility Model is how does > one measure Agility? One way to measure agility is to determine various > degrees of freedom and variability allowed by the system in question. > Considering these Agility Measures, the fewer degrees of freedom and > variability, the less agile the system as a whole. Using the ideas from the > Seven Levels of Loose Coupling as a starting point, would could start with a > basic Agility model as such: > > - Implementation Variability – Projects at the bottom of this > measure of maturity are inflexible with respect to implementation changes, > whereas those at the top allow for changes to Service consumers and > producers without impacting each other. > - Infrastructure Variability – Projects that exhibit poor agility in > this aspect of loose coupling are heavily dependent on the current > infrastructure to provide all the requirements for SOA infrastructure, > whereas those that show greatest agility can accommodate arbitrary changes, > replacements, or additions to the infrastructure without skipping a beat. > - Contract Variability -- Projects at one end of the spectrum don't > allow for flexible change to Service contracts while those at the other end > are immune to such changes. > - Process Variability – SOA initiatives at the bottom of this > agility measure don't allow for dynamic and continuous process change while > those at the top can handle any new process change or configuration > requirement. > - Policy Variability – SOA projects that exhibit weak agility with > regards to policy variability can only handle policy changes through > redevelopment, redeployment, or even infrastructure change, whereas those > that show greatest agility can handle any policy change or new policy > requirement flexibly. > - Data Structure Variability – SOA initiatives that exhibit poor > data structure variability cannot accommodate variations to the > representation of data, whereas those that show greatest agility can handle > such changes without having to refactor Service consumers or providers. > - Semantic Variability – Projects at the low end of the spectrum are > inflexible with regards to changes to the meaning and semantics of > information whereas those that show greatest flexibility can handle > semantic > differences between systems without requiring human involvement. > > The result of the above analysis is a heat-map of sorts. Each project will > exhibit characteristics of agility that might be more flexible at one level, > while less at another. The key is not to achieve the highest level of > agility for all measures, but to create the agility model for the particular > SOA project and compare that against project-specific or broader Agility > Models that act as a baseline for all subsequent SOA projects. In this way, > companies can use agility models for both project planning as well as > auditing and measurement. Companies can also, if they choose, compare their > Agility Models with competing firms in the same industry and across multiple > industries, but this is certainly not the goal of the Agility Model. > > Of course, in a 1500-word ZapFlash, it's hard to truly summarize the > mechanism and methods for determining such levels of Agility. ZapThink has > built significant knowledge and intellectual property in the calculation and > measurement of the above Agility Measures as well as methodologies for > helping companies set their Agility Model for the business on a strategic > and per-project basis. If you want to successfully apply the Agility Model > to your own company, you should approach it both as a project-planning tool > as well as an auditing and measurement tool, keeping in mind that the > projects might be flexible and agile at one level, but not at another. The > idea is not to achieve some abstract "top" measure, but rather to achieve an > optimum. The secret sauce is determining your optimum and finding concrete > ways to measure distributed projects in the enterprise. > > *The ZapThink Take* > It's important to realize that the Agility Model itself is just one part > of a larger collection of activities around agility. Businesses need to > represent their functional and non-function requirements in terms of not > only Service, process, and policy requirements, but also Agility > Requirements. Those Agility Requirements then serve as the basis for > determining how an Agility Model can be defined as a to-be planning > activity. Once this Agility Model Baseline has been defined for the > particular project, organizations can measure subsequent architectural > artifacts and activities using Agility Measures to see how they match up. > The resulting heat-map shows how the actually implemented architecture > measures against planned agility goals. > > Generic, cross-industry measures of maturity, such as CMMI and almost all > SOA Maturity Models, have very little meaning or value outside of its > potential marketing benefit. These generic models provide little guidance on > how to manage or measure ongoing projects, nor do they handle the wide range > of maturity of disparate projects in the enterprise or the necessary > variability across different industry sectors and company types. Nor do > these measures really address the core reality that different projects > should necessarily be at different so-called maturity levels due to business > requirements. > > I believe that most SOA Maturity Models are meaningless measures of SOA > activities against arbitrary measures of architectural capability. Instead, > project-specific Agility Models paired with Agility Plans that indicate how > the enterprise as a wide will deal with projects at different levels of > agility will help to guide SOA implementations as well as provide an > enterprise-wide view of the various projects and how they are contributing > to an organization' s agility. A good Agility Model will help organizations > advance their business to greater degrees of agility on a timeframe that > matches their ability to invest. That matters a lot more than achieving some > meaningless number on an arbitrary measure of maturity. > > > > ------------------------------ > Looking for last minute shopping deals? Find them fast with Yahoo! > Search.<http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping> > > >
