Tuesday, January 26, 2010

Agile Application Modernization?

Is Agile Application Modernization an oxymoron? I have started with the principles as defined by Beck, Beedle, Bennekum, Cockburn, Cunningham et al and suggested some key alterations. Be very interested in all feedback.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Replace

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

With

Manage change to absolute minimum to deliver high quality foundation that can then support continuous delivery of change as necessary.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Replace

Continuous attention to technical excellence and good design enhances agility.

With

Continuous attention to best practice architecture delivers an inherently agile product.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams which can then form the basis for reference architecture and policy.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sunday, January 24, 2010

Getting to grips with Agility

For the past few years the concept of business agility has been much in evidence in vendors’ SOA marketing materials. It is a good idea to promote agility – clearly SOA can deliver inherently agile applications because it increases loose coupling, and in many ways the marketing of the benefits of service architecture has closer relationship with reality than many forms of IT marketing that frequently rely on hype and superficial nonsense.

As SOA marketing spend diminishes to be overtaken by new kids on the block such as Cloud, Virtualization, Green IT, Social Software, Application Modernization and so on, the business agility message is being used ever more widely. No surprise because there is intense post recession interest in managing change as enterprises drive out costs and reprioritize to focus on new business opportunities.

Yet in many cases the use of the term agility is a stretch. At least SOA marketers could reasonably claim that service based products genuinely would reduce coupling. But the core issue is that business agility is an elusive concept and no one gets held to account because the agility offering is unquantifiable. We might wonder how many buyers of SOA products and services feel in retrospect, and whether with 20:20 hindsight they might consider the claims for agility were over stated!

What’s needed is ways to talk sensibly about the topic of agility. I observe efforts to measure agility by measuring complexity. I don’t agree with this – I think it’s fine to measure relative complexity, but this doesn’t help in the understanding of agility. As an aside, the agile methods community have developed ideas around an agility quotient[i] which assesses 11 factors to assess and rate skills and attitudes relevant to agile delivery. But this is quite different to measuring the agility of delivered application capabilities.

We need a technique to facilitate a rational dialog between business and IT managers on the subject of agility. The dialog needs to be an integral part of business requirements planning – that encourages exploration of where business change may occur, where articulation points need to be, and the type of change that may be required, or not as the case may be.

In this month’s CBDI Journal I propose a technique that develops a relative measure of potential agility. I refer to this as Potential Application Agility (PA2). The measure is developed for business processes and or business capabilities and can be used to analyze change to assess the monetary value of agility in different areas of the business and to create a heat map that can inform architecture work. The PA2 measure then provides a useful input into architecture development effort.

I recommend initially developing an “agility architecture” highlighting Policies, Patterns, Standards and Practices for each of the architecture Views (Business, Specification, Implementation, Deployment and Technology). The agility architecture will form part of the reference architecture and with suitable annotation provide guidance and governance to achieving appropriate levels of agility as indicated by the business analysis.

I anticipate a response that says, “we can’t afford the time to do that sort of analysis; it’s inimical to the agile (project) best practices.” My response is – how can you afford not to undertake this form of analysis. In today’s fast moving world, it’s impossible to bottom out comprehensive business requirements. Rather it’s much more important to figure out the morphology of the application and or service in terms of agility and stability and to deliver a stable foundation that can support appropriate levels of adaptability.

The PA2 analysis can be undertaken in an iterative manner and on progressive levels of detail. Initially it would make sense to do it in outline, and then in time honoured fashion to drill down in areas that merit attention. A few hours of facilitated workshop style discussion with the right stakeholders should be more than adequate to achieve an outline agility analysis, and direct more detailed work into areas of serious business value.

Thursday, January 7, 2010

The meaning of life and application modernization

I observe lots of modernization going on that addresses narrow technology concerns – particularly moving to new technology platforms and languages. But there are so many other dimensions that we should be considering.

I have written a lot over the years about how good (fit for purpose) architecture is based on principles, and we might do worse than consider what architectural principles are relevant to modernization.

First the SOA principles of loose coupling, abstraction, contract based and suitably event driven are very appropriate. It would seem strange (a bad investment) if a modernized system was not service oriented. But in addition consider:

  • Model driven architecture and design – enables governance and ongoing management of inter and intra application architecture.
  • Component based implementation – ensures containment of complexity, defined responsibilities, boundaries and dependencies.
  • Virtualized – cloud ready.
  • Application knowledge is a byproduct of delivery platforms and tools – ensuring precise and current documentation of the (business logic and rule) details of the application.
  • Defined change management capability with SLA.

Modernized applications should be model driven (ideally, but not necessarily using MDA/MDD per se) and service and component based in order to achieve the same level of agility and asset management that can be achieved in the service architecture, at the implementation layer. These two principles can easily be measured by the existence of a) models and b) well formed components and are viewed as important characteristics of modernization and key criteria for assessment of existing systems.

A defining feature of legacy applications is the absence of understanding of what an application does. In contrast a modernized application should not be defined solely by being coded in a modern language, but should also have detailed documentation of structure, business rules and logic compliant with a comprehensive meta model as an integral part of the technology architecture and delivery process. In this way currency and accuracy should be guaranteed.

Finally there has been widespread debate about what agility means, but few answers. The obvious way to tell whether an application is agile is to have explicit agility architecture together with a Change Service Level Agreement that provides estimating guidelines for relevant types of change. Then it would at least be measurable.

Everware-CBDI is evolving it's service architecture and engineering framework(SAE) to incorporate application modernization. Resources on SAE2:

Application Modernization Framework (free white paper)

Application Modernization Process (free white paper)

December CBDI Journal – On Application Modernization (on subscription)