sdlc

Ten Things User’s Don’t Care About

Peter Cripps architecture , ,

I recently came across a blog post called Things users don’t care about at the interface and product design blog bokardo. It struck me this was the basis of a good list of things end users of the systems that we architect may also not care about and might therefore help us focus on the things that matter in a system development project. Here then, is my list of ten things users don’t (or shouldn’t care about):

  1. How long you spent on it. Of course, if you spent so long you didn’t actually deliver anything this is another problem. However users still won’t care, it’s just they’ll never know they are missing something (unless your competitor beat you to it).
  2. How hard it was to implement. You may be immensely proud of how your team overcame tremendous odds to solve that really tricky programming problem. However all users are concerned about is whether the thing actually works and makes their lives a little easier. Sometimes just good enough is all that is required.
  3. How clean your architecture is. As architects we strive for purity in our designs and love to follow good architectural principles. Of course these are important because good architectural practice usually leads to more robust and resilient systems. The message here is not to go too overboard on this and don’t strive for architectural purity over the ability to ship something.
  4. How extensible it is. Extensibility (and here we can add a number of other non-runtime qualities such as scaleability, portability, testability etc.) is often something we sweat a lot over when designing a system. These are things that are important to people who need to maintain and run the system but not to end users who just want to use the system to get their job done and go home at a reasonable time! Although we might like to place great emphasis on the longevity our systems might have (which these qualities often ensure) sometimes technology just marches on and makes these systems redundant before they ever get chance to be upgraded etc. The message here is although these qualities are important, they need to be put into the broader perspective of the likely lifetime of the systems we are building.
  5. How amazing the next version will be. Ah yes, there will always be another version that really makes life easier and does what was probably promised in the first place! The fact is there will be no “next version” if version 1.0 does not do enough to win over hearts and minds (which actually does not always have to be that much).
  6. What you think they should be interested in. As designers of systems we often give users what we think they would be interested in rather than what they actually want. Be careful here, you have to be very lucky or very prescient or like the late Steve Jobs to make this work.
  7. How important this is to you. Remember all those sleepless nights you spent worrying over that design problem that would not go away? Well, guess what, once the system is out there no one cares how important that was to you. See item 2).
  8. What development process you followed. The best development process is the one that ships your product in a reasonably timely fashion and within the budget that was set for the project. How agile it is or what documents do or don’t get written does not matter to the humble user.
  9. How much money was spent in development. Your boss or your company or your client care very much about this but the financial cost of a system is something that users don’t see and most times could not possibly comprehend. Spend your time wisely in focusing on what will make a difference to the users experience and let someone else sweat the financial stuff.
  10. The prima donna(s) who worked on the project. Most of us have worked with such people. The ones who, having worked on one or two successful projects, think they are ready to project manage the next moon landing or design the system that will solve world hunger or can turn out code faster than Mark Zuckerberg on steroids. What’s important on a project is team effort not individuals with overly-inflated egos. Make use of these folk when you can but don’t let them over power the others and decimate team morale.

Top 10 Success Secrets for Software Architects

Peter Cripps architecture ,

Peter Eeles, my co-author of The Process of Software Architecting, has a great presentation called  Top 10 Success Secrets for Software Architects which summarises nicely the attributes a successful architect needs to have and also covers the key points from our book. Briefly these are:

Successful Architects… For example they…
1 Understand end-to-end development. Follow a repeatable process.
2 Understand their role. Understand what an architecture is. Understand what an architect does. Understand the benefits of architecting.
3 Manage risk and manage change. Derive their architectures iteratively.
4 Communicate with stakeholders. Document their architectures.
5 Reuse assets. Embrace different types of assets.
6 Right-size their involvement. Select relevant viewpoints.
7 Influence the requirements. Ensure tradeoffs are negotiated.
8 Derive solutions from business needs. Produce business-driven architectures.
9 Refine solutions based on technology. Realize architectures in available technology.
10 Appreciate the broader context. Align their work with the “bigger picture”.

Peter presented this, with more detail around the attributes and examples, on a public call today. For a replay of the presentation go here. The slides are on slideshare here.

A Service Based Development Process – Part 4

Peter Cripps architecture , ,

The first three of these blog posts (here, here and here) have looked at the process behind developing business processes and services that could be deployed into an appropriate environment, including a cloud (private, public or hybrid). In this final post I’ll take a look at how to make this ‘real’ by describing an architecture that could be used for developing and deploying services, together with some software products for realising that architecture.The diagram below shows both the development time and also run-time logical level architecture of a system that could be used for both developing and deploying business processes and services. This has been created using the sketching capability of Rational Software Architect.

Here’s a brief summary of what each of the logical components in this architecture sketch do (i.e. their responsibilities):

  • SDLC Repository – The description of the SDLC goes here. That is the work breakdown structure, a description of all the phases, activities and tasks as well as the work products to be created by each task and also the roles used to create them. This would be created and modified by the actor Method Author using a SDLC Developer tool. The repository would typically include guidance (examples, templates, guidelines etc) that show how the SDLC is to be used and how to create work products.
  • SDLC Developer – The tool used by the Method Author to compose new or modify existing processes. This tool published the SDLC into the SDLC Repository.
  • Development Artefacts Repository – This is where the work products that are created on an actual project (i.e. ‘instances’ of the work products described in the SDLC) get placed.
  • Business Process Developer – The tool used to create and modify business processes.
  • IT Service Developer – The tool used to create and modify services.
  • Development Repository – This is where ‘code’ level artefacts get stored during development. This could be a subset of the Development Artefacts Repository.
  • Runtime Services Repository -Services get published hereonce they have been certified and can be released for general use.
  • Process Engine – Executes the business process.
  • Enterprise Service Bus – Runs the services and provides adapters to external or legacy systems.

Having described the logical components the next step is to show how these can be realised using one or more vendors products. No surprise that I am going to show how these map to products from IBM’s portfolio however clearly your own particular requirements (including whose on your preferred vendor list of course) may dictate that you choose other vendors products. Nearly all the IBM product links allow you to download trial versions that you can use to try out this approach.

  • Rational Method Composer – This enables you to manage, author, evolve, measure and deploy effective processes (SDLCs) tailored to your project needs. It is based on Eclipse. Rational Method Composer allows publishing to a web site so effectively covers the needs of both the SDLC Repository and SDLC Developer components.
  • IBM Business Process Manager – This is the latest name for IBM’s combined development and runtime business process server. As well as a business process runtime, ESB and BPM repository it also includes design tools for building processes and services.  The Process Designer allows business authors to build fully executable BPMN processes that include user interfaces for human interaction. The Integration Designer enables IT developers to develop services that easily plug into processes to provide integration and routing logic, data transformation and straight-through BPEL subprocesses. See this whitepaper for more information or click here for the IBM edition of the book BPM for Dummies. IBM Business Process Manager realises the components: Business Process Developer, IT Service Developer, Development Repository, Process Engine and Enterprise Service Bus.
  • WebSphere Service Registry and Repository – Catalogs, and organizes assets and services allowing customers to get a handle on what assets they have, making it easy to locate or distribute. Also enables policy management across the SOA lifecycle, spanning various domains of policies including runtime policies as well as service governance policies. Included in the Advanced Lifecycle Edition is
    Rational Asset Manager which provides life cycle management capabilities to manage asset workflow from concept, development, build, deployment, and retirement as well as Build Forge integration. WebSphere Service Registry and Repository realises the Development Artifacts Repository as well as the Runtime Services Repository.

So, there it is. An approach for developing services as well as an initial architecture allowing for the development and deployment of both business processes and services together with some actual products to get you started. Please feel free to comment here or in any of my links if you have anything you’d like to say.

A Service Based Development Process – Part 3

Peter Cripps architecture , ,

In Part 2 I discussed how activities in a delivery process could be created from capability patterns that are comprised of tasks and/or activities. Capability patterns are reusable patterns which can be 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. In this post I’ll take a look at what these work products are and how they form part of a contract between capability patterns.

The table below shows the set of work products that are used in the process I have been describing.

Work Product Description Notation
Service Catalogue Catalogue of all services owned or used by the enterprise. May be technical or business, legacy or new/to be provided. Usually implemented as a service registry. WSDL
Service Certificate Identifies a service that meets certain quality criteria. Text
Service Portfolio Plan Describes what services will be provided, when and by whom. Text
Service Portfolio Describes the entire collection of business services that an enterprise uses or plans to use. Text
Service Model Defines the complete hierarchy of business and technical services used or planned to be used by the enterprise. Can exist at a logical and physical level. Contains one or more Service Specifications. UML
Service Specification Defines a detailed specification for each service. Can exist at a logical and physical level. Text/WSDL
Deployed Service A service deployed in the service platform. Jave, MQ etc
Deployed Service Environment A deployed service platform. N/A

This diagram shows the relationships (finish to finish dependencies) between the above work products.

Work Product Dependency Diagram

In this next diagram we can see how  what I’m referring to as ‘contractual boundaries’ can be realised using these work products which are passed between two of the capability patterns I discussed last time.

Contractual Boundaries

Activities produce one or more work products which are consumed by other activities, either in the same capability pattern, or in a different one. This means that provided the input and output work products are agreed the capability patterns can run in parallel or, if needed, at different times. So, one capability pattern, the ‘provide capability’ one in the above example can contribute to the Service Model work product which another capability pattern, the ‘manage service portfolio’ one can contribute to at a later time if need be. Having a common set of agreed work products, which are shared in a repository, becomes the key to having an effective delivery process.

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.

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.

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.

EA Wars

Peter Cripps architecture , , ,

Lots of great discussion in the blogosphere right now on the relevance of Enterprise Architecture in the brave new world of the ‘extended’ enterprise and whether architecture is something that is planned or ’emerges’. This is largely prompted, I suspect, by the good folk at ZapThink asking Why Nobody is Doing Enterprise Architecture (possibly to plant seeds of doubt in the minds of CIOs and send them rushing to one of their “licensed ZapThink architecture courses”). For a nice, succinct and totally dismissive riposte to the ZapThink article check out David Sprott’s blog entry here. For a more reasoned and skeptical discussion on whether emergent architecture actually exists (I think it does, see below) read Richard Veryard’s blog entry here.However… despite some real FUD’iness on the part of ZapThink there are some elements in their argument that definitely ring true and which I have observed in a number of clients I have worked with over the last few years. In particular:

  • Emergence (i.e. “the way complex systems and patterns arise out of a multiplicity of relatively simple interactions“) is, like it or not, a definite factor in the architecture of modern-day enterprises. This is especially true when the human dimension is factored into the mix. The current Gen Y and upcoming Gen V are not going to hang around while the EA department figure out how to factor their 10th generation iPhone, which offers 3-D holographic body-time, into an EA blueprint. They are just going to bypass the current systems and use it regardless. The enterprise had better quickly figure out the implications of such devices (whatever they turn out to be) or risk becoming a technological backwater.
  • EA departments seem to very quickly become disjoint from both the business which they should be serving and the technicians which they should be governing. One is definitely tempted to ask “who is governing the governors” when it comes to the EA department? Accountability in many organisations definitely seems to be lacking. This feels to me like another example of gapology that seems to be increasingly apparent in such organisations.
  • Even though we are better placed than ever to be able to capture good methodological approaches to systems development I still see precious little adoption of true systems development lifecycles (SDLC’s) in organisations. Admittedly methods have had very bad press over the years as they are often seen as been an unnecessary overhead which, with the rise of agile, have been pushed into the background as something an organisation must have in order to be ISO 9000 compliant or whatever but everyone really just gets on with it and ignores all that stuff.
  • Finally, as with many things in IT, the situation has been confused by having multiple and overlapping standards and frameworks in the EA space (TOGAF, Zachman and MODAF to name but three). Whilst none of these may be perfect I think the important thing is to go with one and adapt it accordingly to what works for your organisation. What we should not be doing is inventing more frameworks (and standards bodies to promote them). As with developing an EA itself the approach an EA department should take to selecting an EA framework is to start small and grow on an as needs basis.

Is Agile Architecture an Oxymoron?

Peter Cripps architecture , ,

Much has been written by many great minds on agile development processes and how (or indeed whether) architecture fits into such processes. People like:

  • Scott Ambler (Architecture Envisioning: An Agile Best Practice). “Some people will tell you that you don’t need to do any initial architecture modeling at all.  However, my experience is that doing some initial architectural modeling in an agile manner offers several benefits”.
  • Mike Cohn (Succeeding with Agile). “On an architecturally complicated or risky project, the architect will need to work closely with the product owner to educate the product owner about the architectural implications of items on the product backlog”.
  • Walker Royce (Top 10 Management Principles of Agile Software Delivery) : “Reduce uncertainties by addressing architecturally significant decisions first”.
  • Andrew Johnston (Role of the Agile Architect): “In an agile development the architect has the main responsibility to consider change and complexity while the other developers focus on the next delivery”.
  • Martin Fowler (Is Design Dead?):  “XP does give us a new way to think about effective design because it has made evolutionary design a plausible strategy again”.

I’ve been contemplating how the discipline of architecture, as well as the role of the architect, fits with the agile approach to developing systems whilst reviewing the systems development lifecycle (SDLC) for a number of clients of late. In my experience most people have an “either-or” approach when it comes to SDLC’s. They either do waterfall or do agile and have some criteria which they use to decide between the two approaches on a project by project basis. Unfortunately these selection criteria are often biased toward the prejudices of the person writing the criteria and will push their favourite approach.

Rather than treating agile and waterfall as mutually exclusive I would prefer to adopt a layered approach to defining SDLC’s as shown here.

The three layers have the following characteristics:

  1. Basic Process. Assume all projects adopt the simplest approach to delivery as possible (but no simpler). For most software product development projects this will amount to an agile approach like Scrum which uses iterations (sprints) and a simplified set of roles, namely: Product Manager, Scrum Master and Team where Team is made up of people adopting multiple roles (architect, programmer, tester etc). On such projects decide up front which artefacts you want to adopt. These don’t need to be heavy-weight documents but could be contained in tools or as sketches. Here the team member performing the architect role needs to manage an “emergent architecture”. The role of architect maybe shared or not dedicated to a single individual.
  2. Complex Process. At the next level of complexity where multiple-products need to be built as part of a single program of work and all these have dependencies some level of governance usually needs to be in place that ensures everything comes together at the right time and is of a consistent level of quality. At a micro-level this can be done using a scrum-of-scrums approach where a twice or thrice weekly scrum that brings together all the Scrum Masters happens. Here the architect role is cross-product as it needs to ensure all products fit together (including maybe third party products and packages). This may still be a shared role but is more likely to be a dedicated individual. This may involve some program level checkpoints that at least ensure all iterations have created a shippable product that is ready to integrate or deploy. The architecture is not just emergent any more but may also needs to be “envisioned” up-front so everyone understands where their product fits with others.
  3. Complex Integration Process. The final level of complexity is caused when not only multiple products are being developed but also existing systems need to be incorporated which have complex (or poorly understood) interfaces. Here the role of the architect is not only cross-product but cross-system as she has to deal with the complexity of multiple systems, some of which may need to be changed by people other than the core development team. Here the level of ceremony as well as the number of artefacts to control and manage the decisions around the complexity will increase. The architecture is certainly not emergent any more but also needs to be “envisioned” up-front so everyone understands where their product fits and also what interfaces they need to work with. This is something Scott Ambler suggests happens during “iteration zero“.

Each of these layers is built on a common architectural as well as process “language” so everyone has a common understanding of terms used in the project. I’m much in agreement with Mike Cohn’s comment on his blog recently where, in reflecting on the tenth anniversary of the Agile Manifesto he says: “The next change I’d like to see (and predict will occur) over the next ten years also occurred in the OO world: We stop talking about agile” and goes on to say “Rather than “agile software development” it is just “software development”—and of course it’s agile”.

I would like to see an agile or lean based approach as the de-facto standard that only adds additional artefacts or project checkpoints as needed rather than thinking that every time we need to either adopt an agile approach or a waterfall approach.