Your passion and your process in a few lines and dots.

So we have looked at “why” and we have looked at “what”. Now, Mr. Kipling, we need to look at how.

We need to look at the “how” in several parts:

• Processes, and we are going to look at this 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

Processes
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.

Macro
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 needs to have as many phases as you need to track your project and provide meaningful feedback to senior management as they need. But it need not have so many steps that the granularity of phases becomes meaningless.

A good rule of thumb is 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.

Micro
Within each of these macro-level phases you need to think about what the micro level detail steps need to look like and you need 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 need to 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 need to 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. So will time-frames and sign-offs. 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.

Tools
As we have seen every application development group has a huge extant investment in technologies to support their efforts. Ripping them out and replacing them with something generic but integrated is not the answer.

We need to step up our requirements in the identification and selection of tools for application development. In fact I want you to start to demand two things from each of your vendors starting today:

• Is the tool process centric and does it support a flexible process model? Any tool that insists you follow its model rather than your own needs to be crossed off the shortlist. Insist on tools that are process centric and that support your ability to customize the process without having to write code to do so!
• Is the tool open? Does the tool have an open, standards-based, API and does that include the ability to run the tool without a user interface? Does the API support both a push and pull-model? Can the tools be driven from an event generator? Does the tool generate events. Only with the broadest and most open API will you ever get the depth of integration you need for Orchestrated ALM.

Make these essential requirements in you vendor RFP’s and RFI’s today. Integration at the process level is essential.

Integrations: the other great myth
Point-to-point integrations are the answer vendors say. We can integrate our point to tool their point tool. But when they do the point-to-point integrations are usually limited in functionality, barely offer more than automated cut-and-paste and are all too often very brittle. Upgrade the software at one end of the integration and the integration falls apart. And you the customer are left trying to get to vendors to cooperate on fixing the integration.

Interfaces
Ideally the tools one uses have role specific user interfaces.

There has been a trend recently to create the all-singing-all-dancing IDE with every conceivable feature and function buried in them down amongst many layers of menus. But the one-size-fits-all myth applies to interfaces too. We need role specific user interfaces.

Classes and libraries are jargon that is fine for a developer but resources and collections might be better for a user interface designer. Painting pictures with a stylus might be right for the web designer but a Java IDE is better for the web developer. One size does not fill all.

So this means it is essential to use tools that meet your UI needs not those of the vendor. And if you do not have tool in that part of the lifecycle you can easily create one with the automation of the process steps with your automation tool.

Reports, controls and measurement
If we implement all of these features and connect them together with the automation tool we will be ale to create the kind of reporting dashboards that allow us to manage our business, implement controls so we can ensure the right stakeholders give informed consent to projects as they move through the lifecycle and we will be able to get real-time data, trending over time, so we can see where we are improving development efforts and where we are making them worse.

When we look at most dashboards they are awash with charts and grids and are more colorful than Harlequin’s suit. What we need are the key indicators of performance and we need to limit this to less than ten. For the CIO they might be:

• Percentage of projects delivered on time
• Percentage of planned content delivered
• Percentage of projects delivered to budget
• Percentage of defects reported post delivery

For the VP of App. Dev. they might be:

• Percentage of requirements changed post freeze
• Average number of items in developer queues
• Average number of closed tickets per day
• Number severity 1 issues outstanding more than 24 hours
• Percentage of automated tests that fail
• Percentage of automated test coverage

Whatever we choose as our key indicators we can now have this information delivered to us because of process automation. But another key benefit of automation is the guarantee that processes will be followed and the designated individuals will be able to insert themselves into the process and confirm their approval (or disapproval) at each step of the lifecycle. This is essential for accountability and traceability.

Summary
So you need to define your high-level process. And then our low-level ones.

We implement the high-level ones in our automation too. The low-level ones in the tool of choice for the phase and, if there is no too, we implement in the process automation tool.

We connect the low-level tools to the high-level process via web-services based integrations. We do this based on the process needs not on point-to-point capabilities.

Where there are parts of the lifecycle that are not supported by tools we create the interfaces we need so that every stakeholder is required to participate in the process.

We develop dashboards, controls and key performance indicators based on the automation.

I know it sounds easy and it is really. It just requires effort and dedication supported by commitment and open-mindedness. Not a lot to ask.