Software Development Linkopedia May 2012

Here is our monthly selection of interesting knowledge material on programming, software testing and project management: Blogs: On the importance of focus and feedback Blog: What’s New in Visual Studio 11 Beta Unit Testing Blog: LSSC 2012 Quotes Blog: Agile Coaching Tip: The Quiet Power of Silence Article: The Role of the Product Owner in Moving a Backlog Item to Done Article: Four Principles of Low-Risk Software Releases Article: SOA and Cloud Computing Article: Product Engineering is like Marathon Training Article: Scrum and Agile Trac Plugins Article: Software Testing Certifications Tools: PESTT is an Eclipse plug-in for learning and designing unit ...

What’s your experience of BPM so far?


What's your experience of BPM so far?

The MotherShip
It seems to me that a lot of the work I am currently doing is related to "Let's see what we’ve got and document it" rather than ”OK, I'm wanting to make this more efficient, how can I do that?”.

As an example I spent time last year working with a large merchant bank who were wanting to document their sales process to help them understand how they could better sell to customer. This included understanding what was ”core” to their business and what was ”ancillary, but still profit-worthy”. The whole thrust of the BPM side of things was just to understand what they did and how they did it. We used a process management tool to do this, but at no point where we considering understanding how we could automate this or anything similar to that. It was purely a documentation effort.

My last job, similarly, was with a large aerospace manufacturer who were looking to document their HR processes. They had built up over a period of about 50 years by acquisition and this had resulted in over 250 separate companies being brought into the fold. Each of these companies had their own ways of on-boarding people, promoting people, recruiting people etc. the company wanted to document and define a single method of doing all this and rolling it out to the all the divisions. Again, nothing about automating anything, mostly about documenting.

Now I'm in discussions with a UK based transportation company who are looking to document all their existing internal processes to ensure that everything is being done correctly.

Could it be that my experience is just limited in that I tend to do a lot of the ”Let's document what we do” type of work, rather than any of the ”Let's take what we do and improve it”? Or is everyone in a similar situation? Obviously if you are a vendor selling the tools that do this you're going to have a different view of this. But for the consultants out there who are actually at the coal face doing the work, what is the nature of the work you are doing?

I think it's important to understand where the market is at the moment. There are many tools out there to help document and automate, but if the end customer is more concerned with just seeing what they've already got (or want if they don't like doing ’as-as’ documentation) rather than taking that documented state and doing something with it, then we have a different environment (and a different level of maturity) than if the market was interested in improving and automating their processes to gain efficiencies and ”synergies” (excuse the buzzword).

I'm also aware that in ”the market” there are going to be companies that are more advanced in their thinking, and, indeed, in their projects, than some of the companies I'm working with. They will have documented, improved, automated, and implemented their processes already, either as a stand-alone project or as part of a bigger project implementation. And thats all right. But I'm trying to gauge an overall level of maturity across the people who read this blog.

If we were to look at the CMM scale for maturity I'm seeing companies at level 1 or level 2 when it comes to their processes. I think that a lot of vendors are looking at their clients as being at a level 3 and above. What's the truth to this? (The above statements are based purely on anecdotal, not empirical data)

Look forward to hearing your comments and thoughts.

Reminder: 'The Perfect Process Project Second Edition' is now available. Don't miss the chance to get this valuable insight into how to make business processes work for you. Click this link and follow the instructions to get this book.



All information is Copyright (C) G Comerford
  See related info below

The important of root cause analysis for APIs

I've written before about the relevance to Cloud of the famous Leslie Lamport quote that "a distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.” In the case of APIs, it's also relevant. When an API Gateway is delivering APIs out to clients, such as mobile apps, it needs to provide root cause analysis of any API faults. If an API is returning back the error, it's not enough to just flag this; what you really want is information on why the error occurred. This is the root cause analysis requirement.

APIs generally are deployed in front of existing systems, such as a legacy SOAP service. If the legacy SOAP service returns an error, then that impacts on the REST API which depends on it. That legacy SOAP service itself is probably just a facade into another system (an app server, for example). And it may be the problem If you're just providing management at the API layer, you don't have the ability to provide root cause analysis, to go from "This API has an error" to "This API has an error because we know it depends on this other system which is misbehaving".

We see this benefit spelled out in the Vordel case study for 3 (a mobile telco in the UK).  The case study spells out that:
Root Cause Analysis: The Vordel Reporter reporting structure provides the way to identify common failure points in multi-service transactions. This means that if one service is failing, and impacting the transaction as a whole, the Vordel infrastructure detects this and notifies 3.
http://www.vordel.com/customers/3.html
Root cause analysis is an API delivery requirement which separates out the management of just the API from the management of the application itself. 
Posted in Uncategorized