A Service Based Development Process – Part 2

Peter Cripps architecture , , ,

The basic Service Based Development Process I described previously described an end-to-end delivery process for creating services, whether these be cloud-based services or traditional ones running on a an enterprise service bus. The process consisted of a number of activities (where an activity groups together several tasks) as follows:

  • Business Modelling – Develop business process models to understand the business activities that need to take place. Probably a mix of as-is and to-be as well as manual and automated activities.
  • Solution Architecture and Design – Create the architecture for the solution, decides what services are to be used, what platform and delivery environment (public/private cloud, ESB etc) will be used.
  • Solution Assembly/Implementation – Assemble the services into an application and implement using the appropriate technology. Hopefully much of this will be done using tools that generate the appropriate process flows and pull in the right services.
  • Service Identification – Decide what new services need to be specified (i.e. not already in the Service Portfolio).
  • Service Specification – Specify services, their contracts (functional and service levels).
  • Existing Asset Analysis – What assets does the enterprise already have that could be service enabled (legacy code that could be wrappered etc).
  • Service Realisation – Decide what technology will be used to implement services.
  • Service Implementation – Implement services using the chosen technology.
  • Service Platform Design and Installation – Having decided the service runtime environment design and install it. For cloud-based services this means procuring the right cloud resources.
  • Service Operations and Management – Manage and run the service.
  • Service Portfolio Management – Ensure the Service Portfolio kept up to date.

In the example process we have seen so far each of these activities is composed together in such a way that a complete solution can be built out of a set of services that are deployed into a run-time environment. But that is not the only way these activities can be composed. A better way is to compose activities into capability patterns. Capability patterns are comprised of tasks and/or activities that can be composed into ‘higher-order’ capability patterns or delivery processes. They are reusable patterns which can applied across a range of delivery processes. Capability patterns have input/output work products which together define the ‘contractual boundary’ to which performers of the capability pattern must conform (more on this next time).

The delivery process described in part 1 is actually comprised of four capability patterns, each of which could be a process in its own right, or composed into different delivery processes. The four capability patterns are:

  • Provide Capability: Create a new or updated business process/capability based on user requirements. Uses existing services or specifies new ones where needed. Uses tasks mainly from the Consume discipline group.
  • Provide Service: Specify, design and build a new service according to business need. Certify, publish and deploy the service into the operational environment. Uses tasks mainly from the Provide discipline group.
  • Manage Service Portfolio: Create and maintain a service portfolio with an initial set of specified services. Ensure services are certified. Uses tasks from the Manage group.
  • Provide Environment: Design, build, test, install and run a new environment capable of running services. Uses tasks mainly from the Enable group.

Using the same diagrams as before here are the above four capability patterns laid out in terms of disciplines and phases from OpenUP.

Provide Capability
Provide Service
Manage Service Portfolio
Provide Environment

In the third part I’ll look at the work products which together define the ‘contractual boundary’ to which performers of each of the capability patterns must conform.

The ideas in this blog were jointly developed with my ex-IBM colleague Bruce Anderson.

A Service Based Development Process – Part 1

Peter Cripps architecture , , ,

I have been toying around with this for quite a while. What prompted me to return to it was:

  1. With the cloud hype curve reaching its peak I feel compelled to join in, in one of the ways I know best, method, process and architecture.
  2. It allows me to further discuss the power of using an open, method framework based approach to building delivery processes in a plug-and-play kind of way.

I originally thought of calling this “A Cloud Service Based Development Process” however I think the word ‘Cloud’ is redundant. Whilst this process could be used for developing services “in the cloud” it is actually a generic process that can be used for developing services wherever they may actually be deployed. The process is based on three major components, all of which are in the public domain. All I’m doing is what architects are supposed to do, namely assemble components in new and interesting ways.

  1. Service Based Disciplines (from the CBDI), see here.
  2.  The Open Unified Process (from the OMG’s OpenUP), see here.
  3. The concept of activities and capability patterns from the Software and Systems Process Engineering  Metamodel (also from the OMG), see here.

The process emphasizes the organisational and contractual boundaries for a service-oriented enterprise (SOE) by a separation of concerns into a number of disciplines as follows:• 

  • The service consumer and service provider are clearly separated as these require different skills and can be done by different teams.• 
  • Enabling of SOA via the SO environment is a concern of its own (for example an ESB supports the implementation of services but does not affect their business content).• 
  • Governance (manage) is integrated into everyday work. Example: negotiating the interface for a business service. 

These disciplines (concerns) are shown below.

Process phases are from OpenUP and are: 

  • Inception: Establish scope and define acceptance criteria. Identify key requirements, define candidate architecture and estimate the overall cost and schedule with detailed estimates for the elaboration phase. Identify risks and prepare the supporting environment. 
  • Elaboration: Establish a baselined architecture, produce an evolutionary prototype of production-quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks. Demonstrate that the baselined architecture will support the requirements and establish the supporting environment. 
  • Construction: Complete the analysis, design, development and testing of all required functionality. Iteratively and incrementally develop a complete product that is ready to transition to its user community. Establish that users are ready for the application to be deployed. 
  • Transition: Perform user and acceptance testing to validate the new system against user expectations. Convert operational databases. Ensure users and maintainers and ready to use the system. Perform deployment-specific engineering such as cut-over, commercial packaging and production, sales roll-out, field personnel training. Achieve stakeholder concurrence that deployment baselines are complete and user self-supportability. 

In the diagram below I show how the OpenUP phases combined with the previously mentioned disciplines can be overlayed with a deliver process for creating and deploying services.

The process is shown at the level of activities. An activity groups together one or more tasks and tasks deliver artefacts created by roles. I’ll detail more what each of these activities consist of in the next blog.
The other aspect to this diagram is that of iterations. As I’ve mentioned elsewhere I  believe the agile versus waterfall debate is essentially dead. We should deploy whatever processes make most sense for a particular project that can be accomplished in the most time efficient way possible. Using iterations usually makes sense so any process needs to allow for this as does this one. Each phase is iterative meaning that each iteration has elements of each discipline. You can view iterations as a wave which flows through the end-to-end process, early on the emphasis is on business modelling but also includes elements from the other disciplines whereas later on the emphasis shifts to operations and management even though the business process may still be being refined. 

Like I say, next time I’ll look at what each of the activities in this service based development process consists of and what artefacts they create.

Keeping Your Creative Mojo

Peter Cripps creativity ,

In this article Mary Beth Maziarz proposes nine ways to “screw up your creative mojo”. Sometimes, despite our best efforts, we inevitably find ourselves in a bit of a creative cul-de-sac that we feel unable to get out of. At times like this, or just as a way of approaching our work from a new angle, it helps to try and bring some creative, right-brained, thinking to problem solving. Here’s how Mary’s creativity tips might apply to the world of architecture.

  1. Collect the pieces when they come. Solutions to problems rarely arrive fully formed and on-demand. Sometimes solutions to problems arrive at inopportune times. We have enough digital devices at our disposal these days never to have the excuse of not capturing those thoughts as they occur whether it be in the middle of the night or when out walking the dog.
  2. Stop talking and do it. Architects, especially it seems, are very good at talking around all aspects of a problem endlessly. Sometimes you just have to get on and do it. If you are not sure about something use prototypes or proofs of concept to help crystallize your ideas.
  3. Decide the time is now. Architecture is all about compromise. The role of the architect is, as much as anything, about making decisions based on the best information available at the time. Don’t prevaricate endlessly until you have the perfect solution, you never will!
  4. Detach from critical thoughts and circles.You are your own worst critic, there are always many, many reasons for not doing something but usually only one for doing it. Do what you think is right and learn from your mistakes.
  5. Find and believe in your strengths. Not thinking you are clever enough, educated enough or simply having the right level of authority in your organisation can sometimes prevent you from coming out with that great idea.This is about believing in yourself.
  6. Focus your energies. This is about avoiding the distractions and trivia of everyday life (email, filling in that expense form, tweeting you’re in the coffee shop etc) that prevent us from doing our art. Read Steven Presfield’s War of Art (no, this is not written the wrong way round for all you business “warriors” who have read Sun Tzu’s book).
  7. Try anything. Architects tend to be more logical, left-brain thinkers. Reach out to your left-brain to unblock your thoughts and improve your creativity.
  8. Enjoy the journey and your companions. Getting there is part of the fun. Work with others to make the journey more pleasant. Learn from your colleagues (both junior and senior to you) and let them learn from you. Work together, not against each other and reject the cynics and the ne’er-do-well’s.
  9. Be nice to yourself. It’s increasingly difficult these days to justify that long lunchtime walk or afternoon away from the office as proper work. Enjoying yourself (as part of your work) helps those creative juices to flow though.

How to Avoid the Teflon Architecture Syndrome

Peter Cripps architecture , , , ,

So you’ve sent all of your budding architects on TOGAF (or similar) training, hired in some expensive consultants in sharp suits to tell you how to “do architecture” and bought a pile of expensive software tools (no doubt from multiple vendors) for creating all those architecture models  you’ve been told about but for some reason you’re still not getting any better productivity or building the more reliable systems you were expecting from all this investment. You’re still building siloed systems that don’t inter-work, you’re still misinterpreting stakeholder requests and every system you build seems to be “one-of-a-kind”, you’re not “leveraging reuse” and SOA seems to be last years acronym you never quite got the hang of. So what went wrong? Why isn’t architecture “sticking” and why does it seem you have given yourselves a liberal coating of Teflon.The plain fact of the matter is that all this investment will not make one jot of difference if you don’t have a framework in place that allows the architects in your organisation to work together in a consistent and repeatable fashion. If it is to be effective the architecture organisation needs careful and regular sustenance. So, welcome to my architecture sustenance framework*.

Here’s how it works, taking each of the above containers one at a time:

  • Common Language: Architects (as do any professionals) need to speak the same, common language. This needs to be the foundation for everything they do. Common languages can come from standards bodies (UML and SPEM are from the OMG, IEEE 1471-2000 is the architecture description standard from the IEEE) or may be ones your organisation has developed and is in your own glossary.
  • Community: Communities are where people come together to exchange ideas, share knowledge and create intellectual capital (IC) that can be shared more broadly in the organisation. Setting up an architecture Community of Practice (CoP) where your thought leaders can share ideas is vital to making architecture stick and become pervasive. Beware the Ivory Tower Antipattern however.
  • Tools: If communities are to be effective they need to use tools that allow them to create and share information (enterprise social networking tools, sometimes referred to as Enterprise 2.0). They also need tools that allow them to create and maintain delivery processes and manage intellectual capital of all types.
  • Processes: Anything but a completely trivial system will need some level of system development lifecycle (SDLC) that enables it creation and brings a level of ceremony that the project team should follow. An SDLC brings order to the chaos that would otherwise ensue if people working on the project do not know what role they are meant to perform, what work products they are meant to create or what tasks they are meant to do to create those work products. Ideally processes are defined by a community that understands, not only the rules of system development, but also what will, and what will not, work in the organisation. Processes should be published in a method repository so that everyone can easily access them.
  • Guidance: Guidance is what actually enables people to do their jobs. Whereas a process shows what to create when, guidance shows how to create that content. Guidance can take many forms but some of the most common is examples (how did someone else do it), templates (show me what I need to do so I don’t start with a blank sheet every time) and guidelines (provide me with a step-by-step guide on how to perform my task) and tool mentors (how can I make use of a tool to perform this task and create my work product). Guidance should be published in the same (method) repository as the process so it is easy to jump between what I do as well as how I do it.
  • Projects: A project is the vehicle for actually getting work done. Projects follow a process, produce work products (using guidance) to deliver a system. Projects (i.e. the work products they produce) are also published in a repository though ideally this will separate from the generic method repository. Projects are “instances” of a delivery process which is configured in a particular way for that project. The project repository stores the artefacts from the project which serve as examples for others to use as they see fit.
  • Project and Method Repositories: The place where the SDLC and the output of multiple projects is kept. These should be well publicized as the place people know to go to to find out what to do as well as what others have done on other projects.

All of the above elements really do need to be in place to enable architecture (and architects) to grow and flourish in an organisation. Whilst these alone are not a guarantee of success without them your chances of creating an effective architecture team are greatly reduced.

*This framework was developed with my colleague at IBM, Ian Turton.

Is Designing an Architecture an Oxymoron?

Peter Cripps architecture ,

The word ‘design’ is both a noun (a plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is built or made) and a verb (decide upon the look and functioning of (a building, garment, or other object), typically by making a detailed drawing of it). Given an architecture is something you decide the look and function of, typically by making a drawing of it, saying you are designing an architecture is not as daft as it sounds. Grady Booch once remarked that “all architecture is design but not all design is architecture“. An architecture is what we create by applying good software engineering/design principles (separation of concerns, data hiding, contract-driven design, understanding stakeholder needs etc). An architecture can therefore be something that comes out of the process of design (by applying design thinking). However the architecture itself focuses on the essence of the [software] system and does not get bogged down in the detail.

The Legacy Issue

Peter Cripps comment ,

Much of the work we do as architects involves dealing with the dreaded “legacy systems”. Of course legacy actually means the last system built, not one that is necessarily 5, 10, 20 or more years old. As soon as a system goes into production it is basically “legacy”. As soon as new features get added that legacy system gets harder to maintain and  more difficult to understand; entropy (in the sense of an expression of disorder or randomness) sets in.

Apple have recently been in the news again for the wrong reasons because some of the latest iPod’s do not work with previous versions of Mac OSX. Users have been complaining that they are being forced to to upgrade to the latest version of OSX in order to get their shiny new iPods to work. To make matters worse however Apple do support the relatively ancient version of Windows XP. Apple have always taken a fairly hard line when it comes to legacy by not supporting backwards compatibility particularly well when their OS gets upgraded. The upside is the operating systems does not suffer from the “OS bloat” that Windows seems to (the last version of OSX actually had a smaller footprint than the previous version).

As architects it is difficult to focus both on maintaining legacy systems and also figuring out how to replace them. As Seth Godin says:“Driving with your eyes on the rearview mirror is difficult indeed”. At some point you need to figure out whether it is better to abandon the legacy system and replace it or soldier on supporting an ever harder to maintain system. There comes a point where the effort and cost in maintaining legacy is greater than that needed to replace the system entirely. I’m not aware of any formal methods that would help answer this particularly hard architectural decision but it’s one I think any architect should try and answer before embarking on a risky upgrade program that involves updating existing systems.

Ethics and Architecture

Peter Cripps architecture , , ,

If you’ve not seen the BBC2 documentary All Watched Over By Machines of Loving Grace catch it now on the BBC iPlayer while you can (doesn’t work outside the UK unfortunately). You can see a preview of the series (another two to go) on Adam Curtis’ (the film maker) web site here. The basic premise of the first programme is as follows.Back in the 50’s a small group of people took up the ideas of the novelist Ayn Rand whose philosophy of Objectivism advocated reason as the only means of acquiring knowledge and rejecting all forms of faith and religion. They saw themselves as a prototype for a future society where everyone could follow their own selfish desires. One of the Rand ‘disciples’ was Alan Greenspan. Cut to the 1990’s where several Silicon Valley entrepreneurs,  also followers of Rand’s philosophy, believed that the new computer networks would allow the creation of a society where everyone could follow their own desires without there being any anarchy. Alan Greenspan, now Chairman of the Federal Reserve, also became convinced that the computers were creating a new kind of stable capitalism and convinced President Bill Clinton of a radical approach to cut the United States huge deficit. He proposed that Clinton cut government spending and reduce interest rates letting the markets control the fate of the economy, the country and ultimately the world. Whilst this approach appeared to work in the short term, it set off a chain of events which, according to Curtis’ hypothesis, led to 9/11, the Asian financial crash of 1997/98, the current economic crisis and the rise of China as a superpower that will soon surpass that of the United States. What happened was that the “blind faith” we put in the machines that were meant to serve us led us to a “dream world” where we trusted the machines to manage the markets for us but in fact they were operating in ways we could not understand resulting in outcomes we could never predict.

So what the heck has this got to do with architecture?  Back in the mid-80’s when I worked in Silicon Valley I remember reading an article in the San Jose Mercury News about a programmer who had left his job because he didn’t like the applications that the software he’d been working on were being put to (something of a military nature I suspect). Quite a noble act you might think (though given where he worked I suspect the guy didn’t have too much trouble finding another job pretty quickly). I wonder how many of us really think about what the uses of the software systems we are working on are being put to?

Clearly if you are working on the control software for a guided missile it’s pretty clear cut what the application is going to be used for. However what about if you are creating some piece of generic middleware? Yes it could be put to good use in hospital information systems or food-aid distribution systems however the same software could be used for the ERP system of a tobacco company or in controlling surveillance systems that “watch over us with loving grace”.

Any piece of software can be used for both good and evil and the developers of that software can hardly have it on their conscious to worry about what that end use will be. Just like nuclear power leads to both good (nuclear reactors, okay, okay I know that’s debatable given what’s just happened in Japan) and bad (bombs) it is the application of a particular technology that decides whether something is good or bad. However, here’s the rub. As architects aren’t we the ones who are meant to be deciding on how software components are put together to solve problems, for both better and for worse? Is it not within our remit to control those ‘end uses’ therefore and to walk away from those projects that will result in systems that are being built for bad rather than good purposes? We all have our own moral compass and it is up to us as individuals to decide which way we point our own compasses. From my point of view I would hope that I never got involved in systems that in anyway lead to an infringement of a persons basic human rights but how do I decide or know this? I doubt the people that built the systems that are the subject of the Adam Curtis films ever dreamed they would be used in ways which have almost led to the economic collapse of our society? I guess it is beholden on all of us to research and investigate as much as we can those systems we find ourselves working on and decide for ourselves whether we think we are creating machines that watch over us with “loving grace” or which are likely to have more sinister intents. As ever, Aurthur C. Clarke predicted this several decades ago and if you have not read his short story Dial F for Frankenstein now might be a good time to do so.

The Essence of Being an Architect

Peter Cripps architecture , ,

There are many skills frameworks out there that tell us what skills we should have for ‘doing architecture’. My company has (at least) one and I’m sure yours does as well. There are also organisations that specialise in creating such frameworks (check out the Skills Framework for the Information Age for example). Whilst there are some very specific skills that software architects need (developing applications using xyz programming language, building systems using a particular ERP package and so on) which come and go as technology evolves there are some enduring skills which I believe all architects must acquire as they progress in their careers. What I refer to as being the essence of being an architect. Seth Godin recently posted a blog entry called What’s high school for? where he listed 10 things all schools should be teaching that should sit above any of the usual stuff kids get taught (maths, chemistry, history etc). A sort of list of meta-skills if you like. Borrowing from, and extending, this list gives me my list of essential architect skills.

  1. How to focus intently on a problem until it’s solved. There is much talk these days about how the internet, the TV networks and the print media are leading to a dumbed down society in which we have an inability to focus on anything for longer than 30 minutes. Today’s business problems are increasingly complex and often require prolonged periods of time to really focus on what the problem is before charging in with a (software) solution. Unfortunately the temptation is always often to provide the cheapest or the quickest to market solution. You need to fight against these pressures and stay focused on the problem until it is solved.
  2. How to read critically. As architects we cannot hope to understand everything there is to know about every software product, technology or technique that is out there. Often we need to rely on what vendors tell us about their products. Clearly there is a danger here that they tell us what we, or our clients, want to hear glossing over faults or features that are more ‘marketechture’ than architecture. Learn how to read vendor product descriptions and whitepapers with a critical eye and ask difficult questions.
  3. The power of being able to lead groups of peers without receiving clear delegated authority. The role of an architect is to build solutions by assembling components in new and interesting ways. You are the person who needs to both understand what the business wants and how to translate those ‘wants’ into technology. Business people, by and large, cannot tell you how to do that. You need to lead your peers (both business people and technologists) to arrive at an effective solution.
  4. How to persuasively present ideas in multiple forms, especially in writing and before a group. Obvious really, you can have the greatest idea in the world but if you cannot present it properly and effectively it will just stay that, an idea.
  5. Project management, self-management and the management of ideas, projects and people. How to manage your and others time to stay focused and deliver what the client wants in a timely fashion.
  6. An insatiable desire (and the ability) to learn more. Forever! This job cannot be done without continuous learning and acquiring of knowledge. Everyone has their own learning style and preferences for how they acquire knowledge, find out what your style is and deploy it regularly. Don’t stick to IT, I’ve discussed the role of the versatilist extensively (see here for example). Be ‘V’ shaped not ‘T’ shaped.
  7. The self-reliance that comes from understanding that relentless hard work can be applied to solve problems worth solving. Belief in ones ideas and the ability to deploy them when all around you are doubting you is probably one of the hardest skills to acquire. There is a fine balance between arrogance and self-belief. In my experience this is not an easily repeatable skill. Sometimes you will be wrong!
  8. Know how to focus on what is important and to ignore what is not. If you have not heard of Parkinson’s Law of Triviality take a look at it.
  9. Know who the real client is and focus on satisfying him/her/them. There can be lots of distractions in our working lives, and I’m not just talking about twittering, blogging (sic) and the rest of the social networking gamut. Projects can sometimes become too inward focused and lose track of what they are meant to be delivering. We live in a world where numbers have achieved ascendency over purpose. We can sometimes spend too much time measuring, reviewing and meeting targets rather than actually doing. I love this quote from Deming: “If you give a manager a numerical target, he’ll make it, even if he has to destroy the company in the process”. There is little merit in a well executed project that no one wants the output from.
  10. Use software/system delivery lifecycle (SDLC) processes wisely. SDLC’s are meant to be enablers but can end up being disablers! Always customise an SDLC to fit the project not the other way around.

If all of this seems hard work that’s because it is. As Steven Pressfield says in his book The War of Art:

The essence of professionalism is the focus upon the work and its demands, while we are doing it, to the exclusion of all else.

Sketching with the UML

Peter Cripps architecture , ,

In his book UML Distilled – A Brief Guide to the Standard Object Modeling Language Martin Fowler describes three ways he sees UML being used:

  • UML as sketch: Developers use UML to communicate some aspect of a system. These sketches can be used in both forward (i.e. devising new systems) as well as reverse (i.e. understanding existing systems) engineering. Sketches are used to selectively talk about those parts of the system of interest. Not all of the system is sketched. Sketches are drawn using lightweight drawing tools (e.g. whiteboards and marker pens) in sessions lasting anything from a few minutes to a few hours. The notation and adherence to standards is non-strict. Sketching works best in a collaborative environment. Sketches are explorative.
  • UML as a blueprint: In forward engineering the idea is that developers create a blueprint that can be taken and built from (possibly with some more detailed design first). Blueprints are about completeness. The design/architecture should be sufficiently complete that all of the key design decisions have been made leaving as little to chance as possible, In reverse engineering blueprints aim to convey detailed information about the system, sometimes graphically. Blue prints require more sophisticated modelling tools rather than drawing tools. Blueprints are definitive.
  • UML as a programming language: Here developers draw UML diagrams that are compiled down to executable code. This mode requires the most sophisticated tooling of all. The idea of forward and reverse engineering does not exist because the model is the code. Model Driven Architecture (MDA) fits this space.

In practice there is a spectrum of uses of UML which I’ve shown below in Figure 1. In my experience very few organisations are up at level 10 and I would say most are in the range 3 – 5. I would classify these as being those folk who use UML tools to capture key parts of the system (either in a forward or reverse engineering way) and export these pictures into documents which are then reviewed and signed-off.

Figure 1

An interesting addition to the ‘UML as sketch’ concept is that at least two vendors that I know of (IBM and Sparx) are offering ‘sketching’ capabilities within their modeling tools. In Rational Software Architect the elements in a sketch include shapes such as rectangles, circles, cylinders, stick figures that represent people, and text labels. Checkout this YouTube video for a demo. Unlike other types of models, sketches have only a few types of elements and only one type of relationship between elements. Also, sketches do not contain multiple diagrams; each sketch is an independent diagram. You can however move from a sketch to a more formal UML diagram or create a sketch out of an existing UML diagram so allowing you to work with a diagram in a more abstract way.

Below in Figure 2 is an example of a sketch for my example Hotel Management System, that I’ve used a few times now to illustrate some architectural concepts, drawn using the current version of Rational Software Architect. I guess you might call this an Architecture Overview used to show the main system actors and architectural elements.

Figure 2

I guess the ability to be able to sketch with modeling tools could be a bit of a double edged sword. On the one hand it means sketches are at least captured in a formal modeling environment which means they can be kept in one centrailsed repository and can be maintained more effectively. It also means they can potentially be turned into more formal diagrams thus providing a relatively automated way of moving along the scale shown in Figure 1. The downside might be that sketching is as far as people go and never bother to provide anything more formal. I guess only time will tell whether this kind of capability gains much traction amongst developers and architects alike. For my part I would like to see sketching in this way as a formal part of a process which encourages architects and developers to create models using this approach, get them roughly right and then turn them ino a more formal and detailed model.

Change Cases and the Limits of Testing

Peter Cripps architecture ,

This recent blog entry from Seth Godin on “the culture of testing” set me thinking about software architecture and testing. Is it possible to ‘over test’ applications or systems? Is there a point at which you need to stop testing and let your software ‘go free’ so users can ‘complete’ testing themselves? Let’s be clear here:

  • Software needs testing very rigorously. No one wants to fly on an airplane where the on-board flight control software has not been fully tested.
  • I’m also not talking about the well established practice of releasing beta versions of software where you get together a bunch of early adopters to complete testing for you and iron out the “last few bugs”.
  • Testing software against known requirements is most definitely a good thing to do and I’m not advocating just running your system tests against a subset of those functional and non-functional requirements.

Where it gets interesting is when you don’t overly constrain the architecture so that it allows users to take resulting application or system and evolve it (test it) in new and interesting ways. When defining an architecture we usually talk about it having to address functional as well as non-functional requirements but there is a third, often overlooked, class of requirement referred to as change cases or future requirements. Change cases are used to describe new potential requirements for a system or modifications to existing requirements. Change cases usually come from the specifier of the system (e.g. “in three years time we want introduce a loyalty scheme for our regular guests”). Some change cases however are not envisaged in advance and it’s only when users of the application get hold of it that they explore and find new ways of using the application that may not have originally been thought of. Such applications need to be carefully architected, and tested, such that these change cases can be discovered without, of course, breaking the application altogether.

So, by all means ship systems or application that do what they say on the tin but also lets users do other, possibly more interesting things, with them that may lead to new and innovative uses that the original specifiers of the software had not thought about.