Bringing Agility to Architecture, and Architecture to Agility

This page requires Java support

Agile Architect is run by Andrew Johnston of Questa Computing Ltd.

www.andrewj.com

Agile Architect Articles

If you want to be kept informed about new content, please subscribe to my RSS feed

I've just spent two days at the 2008 Enterprise Architecture Conference in London. It was a very high quality event, with a range of speakers covering topics from pragmatic analysis techniques to how to manage knowledge through the life of NASA's Mars programme, more than any single working lifetime.

Overall there was much less focus on technology (read SOA and modelling tools) this year, and a vigorous and renewed focus on business alignment and business architecture, which, if we can deliver, potentially places architecture where it should be, as the business's agent.

But there's a problem. Good business analysis is fundamental to this, yet several delegates bemoaned the current lack of good business analysts. User organisations often struggle to articulate and abstract their needs, and this feeds into all downstream processes. Modelled requirements are an increasing rarity, poorly substituted by imprecise verbal statements in Word or PowerPoint.

The problem is, of course, not unique to analysts, and may have common cause with the equal lack of architects. Senior architects and analysts both tend to have several big birthdays under the belt, and many learned their trade as developers, gaining both practical method skills and the experience of turning ideas into working code. (The majority of exceptions have other "making it work" experience, such as building networks or running data centres.)

But in the current world of ERP packages and large-scale outsourcing, many organisations no longer build anything themselves. The live classroom has been thrown away.

I have worked with a number of good, keen young analysts, but most work for large supplier companies who still have both well-funded training programmes and the breadth of work to build experience and a broad skill set. These guys and girls can do a good job, but at the risk of higher costs and potential conflicts of interest.

We already know that this may reduce organisations' ability to ensure the right solution to their needs, or assure its quality. Recent observations suggest that organisations who forgoe getting their hands dirty in IT will also suffer an increasing difficulty in creating a clear, concise and structured statement of those needs themselves.

I've been musing lately on why we in IT insist on forgetting so much valuable knowledge. I don't know whether it's because of our youth-obsessed culture and our focus on the newest and best, because of our tendency to prioritise on-the-job over traditional learning, or whether there's simply too much in the "architect's book of knowledge" (ABOK), and we all have to focus on the new to keep up.

I explore two very different examples: the value of understanding RS232 in this 3G+ world, and some recent discussions on service reliability, both of which can be resolved using some quite old knowledge.... (Read More...)

The accept/reject assessments of the Sarbanes-Oxley world are far too binary, as they don't allow an architect to record his true feelings about a piece of work. I have therefore decided that in future I will record my assessments using what I have named the "Tevye Scale of Approval"

I've just spent three enjoyable days at the 2006 Enterprise Architecture Conference in London. IRM did their usual excellent job of making it run like clockwork, and my good friend Sally Bean helped them develop an interesting and varied programme. To my mind the best speakers were Jeff Scott, and Chris Wilson of BP. Another encouraging sign was the presence of a great many International delegates.

I presented a paper on Agile Architecture. If you regularly read my work you'll recognise many of the ideas, but I've managed to bring them all together for the first time. You can download my slides and script here.

What was very interesting was how the thrust of the material has changed from a few years ago. No-one was claiming that a given framework, process or toolset can solve EA problems. At the risk of being uncharitable I thought John Zachman's ideas sounded very tired, and there was almost no mention of alternative frameworks such as TOGAF. I may have self-selected by not attending any vendor sessions, but there was also no promotion of tools or technology. A common view was that EA, SOA and many supporting concepts are currently entering the trough of the hype cycle.

Instead the focus was largely on people-related problems and approaches. The labels varied, but several speakers introduced ideas familiar to agile architects. Maybe we're doing something right after all.

Just in case you haven't already seen it.... Why you need architects, in song and dance. Enjoy!

I am looking for one of my clients into how costs can be reduced, or quality increased, by increasing the extent to which testing is automated.

As a first step, I am trying to develop a comprehensive list of test automation "best practices", grouped roughly by life-cycle (or iteration) stage. I'm trying to find practices which are broadly independent of specific methods and technologies, although obviously tool support may vary depending on the chosen technology.

The following is my first draft of such a list. The tools mentioned are simply examples - there are several tools available in each category, both full cost and open source.

I'd welcome suggestions from my readers if you think there are any omissions (or if you substantially disagree with anything I've included).

Thanks

Andrew

Unit and System Testing

1. Suite of automated unit and system tests, which can be run on demand by the developers and before integration.
2. Test-driven development process, in which unit tests are developed before the code they test.
3. Unit and system tests built into the product suite, using one of the xUnit family of tools.
4. Daily or continuous integration process, which includes execution of the test suite.
5. Use of virtual machines or other "cloning" technologies to create easily reproducible development and test environments.
6. Code coverage measured using a tool such as NCover, and demonstrated to be 100% (or as near as practically possible) for all code.
7. Code coverage validated using mutation testing (using a tool such as Jester) to confirm that every line can affect the outcome of at least one test.
8. Feedback process to enhance test suite for bugs discovered in later test stages or live use.

Integration Test

1. Automated end-to-end tests, run for every release.
2. Functional coverage measurement, possibly combined with traceability mechanism between requirements and tests.
3. Ability to easily create and reset an environment which functionally matches production.
4. Automated test management and reporting, providing control/confirmation of tests run, pass/fail results, errors and diagnostics and resolution tracking.
5. Repeatable and automated performance and/or stress tests
6. Ability to inject/extract test messages and files into and out of interfaces and to track them through any integration scheme, ideally in production as well as test environments.
7. Repeatable, pre-prepared set of test messages/files which test all interfaces, including exception handling.
8. Feedback process to enhance test suite for bugs discovered in later test stages or live use.

UAT

The nature of user acceptance test is that most functional testing will be manual, since this will provide maximum independent assurance to the users. The following focuses on where automation can best support the process:

1. Ability to easily create and reset a UAT environment which functionally matches production.
2. Automation for set-up, background and repetitive tests.
3. Automated test management and reporting, providing confirmation of tests run, pass/fail results, errors and diagnostics and resolution tracking.
4. Ability to inject/extract test messages and files into and out of interfaces and to track them through any integration scheme, ideally in production as well as test environments.
5. Feedback process to enhance test suite for bugs discovered in live use.

Production Support

1. Automated and non-destructive end-to-end and integration tests, which can be run on demand following any production change, or as an initial diagnostic action.
2. Ability to inject/extract test messages and files into and out of interfaces and to track them through any integration scheme.
3. Regular automated execution of key tests to verify system performance.
4. Automated test management and reporting, providing confirmation of tests run, pass/fail results, errors and diagnostics and resolution tracking.

If anyone is interested in hearing more about my views on architecture, and how agile methods apply to the work of the architect, please sign up for the 2006 Enterprise Architecture Conference in London in June.

I'm presenting a paper entitled "The Agile Architect". This focuses on both how agile projects can have a strong architecture, and how architects can learn and benefit from agile approaches. I take a rather different approach to some recent papers with a similar title (e.g. at this week's otherwise excellent Microsoft Architecture Insight conference), which suggest that agile projects can "do away with the architect".

I look forwards to seeing you there.

Andrew

I don't really believe in a common architectural process. As the author of a successful project management book, and recent articles on data architecture methods, I probably shouldn't say this, but to paraphrase a famous quote, "When I hear 'process', I reach for my gun!"

This is a story of a project I worked upon which followed an informal, agile process, but delivered a successful architecture. Hopefully it serves to support my assertion that agile can have an architecture, but needs an agile architect.

There's a perennial discussion in architecture forums like the WWISA about the role of the architect, and the discussion regularly degenerates into a debate between the broad and narrow views of what the architect does.

But I'm not sure that's the key question. I think the right question is "Who are the architects?"

Somehow, a number of tasks must be discharged, but how varies from project to project. In the last year I've had a modest building project which tells an interesting story about how different people contribute to "the architecture". Read more here...

Almost all integration projects contain one or more transformations (sometimes called "mappings") between two different structures holding equivalent data (for example the order tables in the database, and the order XML message). We know how to model the individual static data structures in various ways, but the most common approach is to represent each by a UML class model, and there are established conventions for how to do this for different data sources.

However, UML doesn't help when it comes to the transformations themselves, and typically the detail has to be captured either in code, or a proprietary format. Most good integration tools provide some sort of "visual mapping tool", where the developer drags and drops to create links between representations of the two structures, usually imported directly from their physical schemas. Here's an example using SeeBeyond. Altova provide a good stand-alone data mapping tool called Mapforce - here's an example showing it in use. The problem is that these tools work directly with the physical structure, and don't export the mapping information in a reusable format, so that information is completely disconnected from the UML analysis or design models.

I have experimented with trying to represent mapping information in a UML model, but so far without much success. The best solution I've found so far is to use some sort of "pseudo code" (it could be OCL, pseudo-Java, pseudo-VB or anything similar). For example, we could easily annotate the model with code fragments such as:

Database.order_table.order_no = Message.Header.OrderNo

(where each element refers to a UML Package.Class.Attribute combination).

The problems are that it's not clear where to put this annotation, most UML modelling tools won't help generate it, and there's no graphical representation. Ultimately, writing pseudo-code like this is probably not much better than abandoning the model and moving straight to using your integration tool.

My question is: does anybody know a better way? Has anybody found a good way of representing mapping information in UML? And if so, is there any good tool support?

If you know, please send me a message.

There's been a lot of talk in recent years about a "city planning" metaphor for Enterprise Architecture development. Pat Helland's article "Metropolis" in the Microsoft Architecture Journal is a very good example (see my post on this for some key quotes).

While the metaphor might still be valid, some people are beginning to question how far it should be taken. Helland's article, like others before it, implies that "good" EA looks rather like a medium-sized modern American town, complete with relatively standard services, civic buildings and commercial venues. In an answer to the original "Metropolis" article Richard Veryard and Philip Boxer have published "Metropolis and SOA Governance" which challenges several of Helland's assumptions.

I think that maybe we should extend the metaphor by thinking about cities, or Enterprise Architectures, as very diverse entities. What sort of "city" do you live in? To what extent is it planned? What is the vision, and do the citizens share in it? Does the EA resemble a nice neat midwest town, a dark, brooding Gotham City, a glass and steel Utopia, a federation of small towns with lots of empty space between them, a medieaval walled town, or a wartime mid-european ghetto?

And the metaphor can be taken further. Do you want to promote "infill development", closing up functional gaps, or do you want to keep clear separation between the various zones? Do you want the shared services to be clearly visible, as they are in modern, purpose-built towns or hidden beneath a facade which looks much older or simpler? Do you expect to eventually knock down and rebuild older "legacy" zones, or do you want to preserve them with the minimum of change (a common requirement for our valuable historic buildings)? Do you want to accomodate the small hardware shop (read small the bespoke system) as well as the new DIY superstore (the ERP package)?

Finally, remember that it is extremely rare for a city to be truly planned and designed from scratch. You usually start with something established. Even if the city has been flattened by a bomb, you'll have to observe land rights (this is what stopped Christopher Wren and Charles II realising their grand design after the Fire of London). This is equally true of Enterprise Architectures.

The city planning metaphor is a powerful one, but its true power may come if we use it to explore problems as well as utopian ideals.

I've just posted my review of Gregor Hohpe and Bobby Woolfe's excellent book on Enterprise Integration using messaging, "Enterprise Integration Patterns". Overall it's an excellent book, and wiil probably become a "bible" for those involved in the high-level design of integration solutions. To find out more, please read my review.

Apologies to my regular readers if it looks like a lot of items have changed. I've just created "PermaLinks" for each entry in my blog, so you can read my wisdom in the future even if I re-organise my thoughts page!

Keep reading!

Andrew

I've just read an excellent paper by Pat Helland of Microsoft, in which he likens the development of cities and manufacturing in the 19th century to the development of systems and business models now. His conclusion - IT at the moment is about at the same stage as America in the 1880s, when they were just starting to turn the Wild West into an industrialised nation!

Three short quotes from Helland's conclusions bear repeating directly. On heterogeneity he says:

Remember that heterogeneity happens. Unless you have a very simple application portfolio, shared services will not be achieved by trying to put all of your applications on one version of one platform. Even if you could, the next merger would change that! Rather, you have to design for interoperability and integration across platforms. This is the force that is driving the industry wide work in service-oriented architectures.

He extends the popular "city planning" metaphor to IT investment:

IT investment is a balance of funding the sacred, protecting historic monuments, and allocating spending between infrastructure and business opportunity. Striking this balance is a key facet in effective governance, and in realizing the potential of IT in your organization.

And finally, those who seek to maintain control of their enterprise architecture through heavy governance would be well advised to note:

You have to maintain a light hand. It is counterproductive to try to dictate what happens in every structure in town, what color shirts are made, and how much is charged for soap. You have to embrace the semi-autonomous approach to governance that is characteristic of our cities, and allow the process owners to optimize and achieve efficiencies with as few constraints as possible.

Arnon Rotem-Gal-Oz has set up an interesting new site / blog dedicated to software architecture. Of particular note, he's trying to put some detail on the architecture "process" which is often negelcted as a single box on the development process picture. His approach has the name SPAMMED, catchy, but might cause the odd problem with email filters :)

There seems to be quite a lot of activity on the "Domain Specific Language" front at the moment. Martin Fowler published "Language Workbenches: The Killer-App for Domain Specific Languages?", in which he concludes that the common programming pattern of setting up repeating data structures via either very similar lines of code, or an external configuration file, is actually a DSL. He also republished a paper by Dave Thomas entitled "Design to Accomodate Change" on the related topic of table-driven programming.

However, Martin's essay goes beyond common programming and data techniques to look at the development of specialist tools which he calls "Language Workbenches". I'm not completely convinced that we need these in the world of XML and XSD. If you have a defined schema for you XML-based DSL (and aren't all the many *ML langauges just different DLSs?) then any schema-sensitive editor will provide you with good design and editing support. The leading IDEs (e.g. Visual Studio) all have such a tool built into their core capabilities. Surely we now have a sufficiently sophisticated set of XML-based tools and standards that we have an opportunity to exploit synergies rather than re-inventing the wheel?

In an interesting echo of my last piece (Why Software Isn't Like Building Construction), Scott Ambler has analysed bureaucratic processes as a response to management fear about what can go wrong in software development. His conclusion is that these processes only give the illusion of addressing the underlying fear. His article is well worth reading.

Many software development and management methods are founded on a basic assumption - that constructing software is rather like building a bridge or a house. Once we've "done the design", actually generating the software ought to be a completely predictable, relatively low-skilled process. However four decades of failure to achieve this vision might suggest that we should revisit the assumption.

In a paper entitled "The New Methodology" Martin Fowler, the guru of object-oriented development, suggests a couple of reasons why this might be.

My article answers Martin's, suggesting a couple of other considerations, and whether we have to completely abandon the physical construction analogy as a result.

I recently attended a day of the Butler Group "Application Development Strategies" Symposium. I've just posted a short report on some of the more interesting discussions and presentations.

Almost all of the presentations shared a reminder that we still have a "software crisis" - the vast majority of software projects fail to deliver to their original targets and estimates. The presentations suggested three independent, but not exclusive, approaches to try and resolve the problem:

• Adopting better, more agile processes to address fundamental weaknesses in "waterfall" processes,
• Adopting better tools and techniques to improve development productivity and the integration of the application life-cycle,
• Enforcing a stronger "enterprise architecture" framework for development.

This last one was surprising, with several papers echoing my view that a strong architecture is essential if agile development is to succeed on a large scale or in complex and critical applications.

There was also surprising agreement on things which won't solve the problem:

• No-one was promising a technical or product "silver bullet". This includes web services!
• No-one was suggesting that we should just "try harder" with old-fashioned tools and processes.
• There's no "one size fits all" solution. For example it's a mistake to force a formal, high-ceremony process onto small business systems developments.
• Excessive technical standardisation is also not the answer. The drawbacks include "lowest common denominator" technical solutions and inflated costs where the standard solution is "overkill".

Read my report for more details.

Integration, like other design activities, can benefit from sharing ideas and proven strategies in the form of patterns. An excellent starting point is Gregor Hohpe and Bobby Woolf's Enterprise Integration Patterns website and book.

In my recent work I've discovered a few patterns of my own, and I've started a page to document them.

First up is entitled "Change Indicator" . You may have a legacy system with an EAI adaptor, or a similar source of messages, which reports on the current state of key business objects. The messages will typically tell you when something has changed, but not necessarily what has changed, but the latter may be important to downstream systems. This pattern shows how to use EAI elements to add this information in a way which is totally transparent to the legacy system and existing users of the EAI scheme.

In Extensibility Points, Gregor Hohpe describes architecture as a guessing game, trying to understand future changes to a business, and designing a system to cater for those changes. He's written a good article on types of extensibility and where they can be applied.

But Gergor's article doesn't really touch on understanding the dynamics of business change, and how these should dictate the form of architectural extensibility. Neither does he discuss the problem of being an architect who understands what flexibility is required, but being unable to get either the customers, or the suppliers, to agree. I seem to spend a lot of my time saying "I told you so" when a problem I predicted occurs - this is frustrating, even if I'm being proven right.

If you want to understand more about the dynamics of change, you might look at my previous postings on the subject:

Architects - Masters of Order and Unorder

Business Flexibility

Strategies for Flexibility

In a recent article, Gregor Hohpe asks "Is SOA Like Drunk Driving?" In our attempts to address the shortcomings of component-based development have we "swung too far" and introduced new problems?

One recent experience suggests to me that we may well be at risk of this. Read about my first experience of Web Service development and judge for yourself: have we thrown the baby out with the bath-water?

I've recently been catching up on the Microsoft Architecture Journal. This is an occasional MS publication, which can be downloaded from the .NET Architecture Center. It's got a lot of good articles, with a software architecture and process focus.

Of particular interest, there's an article in the first edition by Cap Gemini on "Enterprise Architecture Design and the Integrated Architecture Framework". Obviously every consultancy has their own architecture framework, and they all share some features, but what makes this one a bit different is the strong focus on the contextual (business context), conceptual (vision) and logical (solution independent capability) aspects, with technical details relegated to a bottom physical layer. It also has one of the best discussions I've seen on the relationship and differences between enterprise and project architectures.

Sometimes formalised modelling techniques like UML are not the best solution. Microsoft have recently started talking about "Domain-Specific Languages", specialised modelling techniques for specific tasks. My Domain-Specific Modelling Techniques page outlines some useful DSLs I have developed or discovered.

Inspired by an article on Richard Veryard's SOAPBox Blog, this piece considers the business equivalents of expansion capabilities like the spare slots in a desktop PC.

Do you work in an ordered environment, where things follow rules in a nice, predictable way? Or does your environment exhibit "unorder", characteristics of complexity or chaotic behaviour. If the latter, you need to read this paper to understand how your domain may differ from others, and appropriate techniques to use as an architect, analyst or designer.

Is IT architecture about the "hidden bits of plumbing", or should it focus on the "visible design" delivered to users, developers and other stakeholders? Read this paper, and consider your view.

Unlike the simplistic models in books and training courses, a real enterprise has a very complicated data architecture. Most of the data will be held in large legacy or package systems, for which the details of data structure may be unknown. Other data will be held in spreadsheets and personal databases (such as Microsoft Access), and may be invisible to the IT department or senior business data administrators. Some key data may reside in external systems maintained by service providers or business partners. To manage this you need powerful, simple, but effective models of the data structure from an enterprise viewpoint -- a set of models known as the "Enterprise Data Architecture."

This article, co-written by Richard Wiggins and originally published in the Rational Edge in February 2003 describes a new approach, based on UML, which meets the real requirements of modelling the Enterprise Data Architecture.

Is Architecture an Addiction?

This rather tongue in cheek piece was inspired by a "group therapy" session at the IRM/Meta group Enterprise Architecture Conference 2004.

In "Waltzing with Bears" Tom DeMarco and Tim Lister introduce the very useful concept of the "Uncertainty Diagram", the probability distribution for project metrics such as delivery date, expenditure or benefit delivery. This is used, for example, to assess the likelihood of delay from a given risk.

However, they rely entirely on Monte-Carlo simulation. I believe that where the curve is defined by, or can be approximated by, a few discrete points, a relatively simple analytical solution can then be used in place of simulation.

My musings on what makes a good software architect.

An IT architect (for want of a generic term which isn't already terribly overloaded) takes on many different roles over time. This article discusses some of those roles, and introduces a model for the different architectural interventions in a typical project life-cycle.

Philippe Kruchten of Rational has taken the Tao of Lao-Tsu, and created a modern translation focussed on the values and attitudes which an architect should adopt. He says many things which are also said on this site, but much more beautifully.

Musings on whether an architect can fit neatly anywhere in a traditional IT organisation hierarchy.

"Technical Reference Architecture for Component Based Development and Enterprise Application Integration" by Tim Barrett of ComCor IT Solutions BV is an excellent summary of the characteristics of a strong, flexible, layered and component-based architecture, and the different classes which comprise one. (Adobe Acrobat Format)

Organisations need to protect and maximise the value of their IT assets. To protect against threats from business and technological change systems need to be flexible: able to change to support new functions, new workloads and new working environments. Flexibility does not happen by accident - it is usually the result of planning, forward thinking and adopting strategies known to enhance and encourage it.

This paper (in Adobe Acrobat Format), originally published by the CBDi Forum, presents some of those strategies.

Here's a list of useful articles by Scott Ambler on either the Agile Modeling or Agile Data web sites. A lot of that material is relevant, but I've picked out a few articles which are most relevant to the Agile Architect:

Coming Soon

The following articles related specifically to the Agile Architect are currently under development:

• A War Story About Agile Architecture
• Architecture, Design and Engineering
• Balancing Goals and Constraints
• Modelling Change: Scenario Analysis and Change Cases

Technorati

View my Technorati profile.

Search for references to www.agilearchitect.org

© Questa Computing Ltd. 1999-2005
Page last updated 20 June, 2009 17:54