Thursday, June 30, 2011

A Service Based Development Process - Part 1

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. 

      Wednesday, June 29, 2011

      Keeping Your Creative Mojo

      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. 

        Friday, June 17, 2011

        How to Avoid the Teflon Architecture Syndrome

        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.

          Tuesday, June 14, 2011

          Is Designing an Architecture an Oxymoron?

          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.