So we have looked at “why” and we have looked at “what”. Now, Mr. Kipling, we need to look at how.
You can refresh your memory by reading my previous posts on Orchestrating Application Delivery:
- Part 1 (why)
- Part 2a (what)
- Part 2b (what)
We will look at the “how” in several parts:
- Processes: in terms of micro and macro processes.
- Tools: the underlying data storage they use, the processes they encapsulate and the integration points they offer.
- Integrations and the other myth.
- Interfaces: how the user interacts, if the user interacts.
- Reports, controls, measures and the whole battery of mechanisms that make Orchestrated Application Delivery the reason we are making the this quantum leap.
In the quest for the perfect development process we strive to create the one, the simple, the direct, the optimized definition of how we develop software. When we follow this path we inevitably run into trouble. There is no such thing as the one path for development. Better we try to solve the problem in chunks.
Start by defining the macro-level process into major phases that are meaningful to your development process. You probably have this already. You most likely call it your SDLC, your software development lifecycle. In the most straightforward terms it is the process from the Demand arriving at the door of IT, through the Development phases that design, create and test the solution to the Deployment of the solution into the production environment. Or Planning, Analysis, Design, Implementation and Maintenance (according to Wikipedia) or any one of a hundred different methodologies.
This macro-level process needs to have as many phases required to track your project and provide meaningful feedback to senior management. However, keep it high level so that the granularity of phases isn’t meaningless. A good rule of thumb is to pick an odd number of phases between 3 and 9 and you have the right number. Implement these phases directly in your process automation tool. From this you will create business-level dashboards.
Within each of these macro-level phases think about what the micro-level detail steps need to look like and then think about how they will be implemented. Will a tool be used extensively in this phase? If so does the tool have the ability to implement the process model you need for this phase at a detailed level? Does the tool have the ability to communicate to other tools in the lifecycle? Does the tool have the ability to communicate with the high level process automation tool managing the SDLC, macro-level?
Perhaps we have no tools at all. In which case we must automate hand-offs and sign-offs so that everyone involved in the project is included in the automation. Essentially, we need to create interfaces for them to interact. What if there are point-solution tools that are completely isolated in one phase and have no integration points?
Next, we should ask if the process steps in the phase will be the same each time through. The answer ought to be yes but before we rush to that answer, consider these possibilities:
- We have web, client-server and mainframe development. Tools will certainly be different. Time-frames and sign-offs will also. Perhaps they need separate micro-level processes.
- We have agile, lean and waterfall development styles. Inputs and outputs may be different; measurement certainly is.
- We have high risk projects, mission critical projects, time-to-market sensitive projects. These often lead to different development processes at the micro-level.
- We have new development, enhancement, maintenance and emergency projects. Are their processes the same?
We need to implement the micro-process in the tool of choice for that phase of the lifecycle or we need to introduce automation using our process automation tool of choice. I’ll talk about tools, integrations, interfaces and reports in my next post.