Controlled Agility

Risk Management

I've been reading up on Software Risk Management for a little while now. And the best information I've come across comes from the SEI. The following is a list of papers that I've read and some key points from them that validate some of my pre-existing biases. To come clean my biases are that the whole team should be involved in risk management on a day-to-day basis. Every member of the team, from the newest graduate, to the most bitter linux admin can have some valuable insight into the risks of a project. The trick is to operationalise this view into a bottom-up workflow oriented tracking application that allows cross-project historical reporting.

My previous experience with Risk Management is that PMI-style Project Managers do a risk analysis up front and then pretty much forget about it in the cut & thrust. Of course, the PMI will have you believe that PMs will do continual reviews, but if the process is not embedded in MS Project, then it ain't done. But, not another rant on the aspects of PMI.

Software Risk Management

Talks about continuous risk management, which is that risk communication must occur in all directions in an organisation. Eg developers are often the best to know when something poses a risk, and there needs to be a way in which to capture this information that will bring it to the attention of the risk managers. Overall, a fairly good article.

An introduction to Team Risk Management

Defines an overall process for risk management. In particular it highlights the supplier/customer shared management of risk through a master risk log etc. It actually defines a workflow for risk management. It lists all the key operations that can be done to a risk. In many ways this document is a high level functional specification for a risk management system to be built in a tool such as jira.

Taxonomy Based Risk Identification is a tremendous document that creates an checklist for the identification of risk. It creates three major groupings of risk, Product Engineering, Development Environment and Program Constraints and procedes to itemise areas where risk can occur. They even developed a questionnaire that helps elicit the risks from key stakeholders. Borland (through the terraquest acquisition) have operationalized this into something they call "Risk Factors". Of course, they've applied a product-sell slant to it as well. This risk taxonomy is a great seed for an organisation's risk database. The organisation could easily add customised areas of risk to this taxonomy where they've found through their own Continuous Risk Management to have been caught short. A taxonomy of operational risk looks like it supercedes the above. In essence it applies the software risk taxonomy to operational tasks. It defines operational tasks as customer service units, military units, and satellite ground stations - whatever that grouping helps clarify. The document seems to specialise the taxonomy, but it looks like it generalises it too. A bit confusing.

Continuous Risk Management is a book I'd like to get my hands on. It looks like it's the whole kit from SEI. 

The final paper I read from the SEI on risk was Software Risk Evaluation Method Description. This paper is brilliant. It operationalises risk elicitiation and discovery for projects. It strings together the taxonomy questionnaire in a "flawless" based method. It gives step by step guidance on how to run a risk workshop, who needs to have buy-in, how to structure the risk report and finally, how to convert your efforts into a risk database. Awesome. Apparently, there is a field book and a cd of instructional videos so that you can watch a risk workshop in action. I can't get over how valuable this can be. I cannot wait to get my hands on this stuff from the SEI. I'm ordering it soon.

tags: risk management,

Real Options Pricing Of Software

Found some interesting papers on this gentleman's site via Steve Neiderhauser. He's a professor in the School of Management at Boston College. He writes about IT operations from a management science perspective. This puts him in a very small minority. Most people who write about IT Management are from an engineering background, hence PMI et al.

He writes about three things which are quite pertinant to this SOA thing. Firstly, Real Options valuations. Options as you all probably know are a way of valuing the option of something. This is implicitly applicable to software. When you deploy a piece of software, you get certain options to go forward. This value never gets reflected in NPV. I think I read the same article that inspired this guy in a Mckinsey Qaurterly back in '99. When I read it, it immediately resonated just like it does today. He goes further than just resonating, he writes about different types of options enabled by IT systems and some caveats. Excellent stuff.

The next SOA-applicable thing is his work on reuse. His papers on reuse are dated since they deal with OO reuse of the late 80s, early 90s. But there are parallels between Service Reuse and Object Reuse. He talks about incentivisation and costing models to enhance the reuse of an organisation. In particular the article that talks about incentives is a thorough treatment of the various organisational forms invented to promote reuse. Many of the issues he covers, such as reuse funding, are very germane to the notion of services. Interestngly, he quotes quite a few of the scions of OO thinking back in the day - all of their theories, bunk.

Lastly he talks about the assimilation of innovation in an organisation. He talks about the barriers to assimilation and other characteristics of technology diffusion. Again, his case studies are more from the OO world, but the concepts are directly applicable to SOA.

I haven't fully assimilated all his concepts, but I've del.icio.us'd them for future thinking. If your into IT Governance the papers are well worth the price of admission.

tags: real options, options pricing, ITGovernance

is EA the new BPR

I attending a seminar put on by Borland where they had a Gartner analyst present some talk about IT Governance. It was a thoroughly vacuous presentation. There was no meat, full of flowery triangles involving people, process and technology. During the presentation I realised that I'd been here before. I've been in BPR presentations that were exactly the same. I substituted the word "BPR" for 'IT Governance" in this gentleman's slides, and they made complete sense! There was no issue with the meaning - because the slides where meaningless.

Another similarity between ITGovernance and BPR is the fact that individual consultants seem to be making a killing in this area. Perhaps it's more a reflection of the life-cycle of Service, that individuals jump the gun on the bigger vendors, I'm not sure. But there are a lot of poorly qualified people implementing EA frameworks, talking shite, and I'm not sure they're providing value.

There's another aspect to BPR that I think bears drawing out. BPR was killed by the ERP train. Who cares about re-engineering your processes and the needless pontificating about this that your middle managers will do when you can just buy a process. Where is the ERP4IT gorilla? who will be the SAP of this space?

tags:enterprise architecture, bpr, ea, erp4it, business process re-engineering

Scott v Charles

James asks about a funny exchange that occured on the erp4it mailing group.  I think James is asking about the nature of the debate, which I shan't address here. I want to highlight just one paragraph, without being sycophantic, that James himself contributed to this debate. That for me crystalises the entire debate.

"So maybe the problem space states that Charles is the transparency pundit and that Scott is the productivity pundit and that these two shouldn't throw in the towel but instead seek to find the chaordic balance between them." ...

To me, that's it in a nutshell - why controlledAgility

 

Counting Source Statements

Accidently dropped into the SEI site the other day and was trapped. More on this in a later post about "Indicators". For this post, I want to point to this article about counting lines of code. Gosh, it's a warrens den trying to count source in various languages. It's so complicated, it makes Function Points look like child's play. And even after all this effort of counting source lines, I can't see how you can use it to effectively estimate anything. I just cannot think in lines of code.

tags: sloc, function points

Reusable Asset Specification

Just to hand. Found this specification somehow.  It's all about dependency management. But dependency of artifacts. So things like documents, diagrams, source, interface definitions, etc. The idea is that your tool creates a .ras file that has a manifest.xml document that describes the artifact and it's associations. This definition then tells you where you can configure this component, how well it's tested, how well it's documented, etc. Very interesting in terms of "configurable item" and things of that nature. It's a concrete example of how something like CI might start to work. Though I'm no expert on ITILs CI, but do have trouble understanding how it will work in the field.

The contributors are from the component marketplace and the "application understanding" (ie, Adaptive, LogicLibrary) space, and ibm which is a space unto itself.

Amazingly, there's already a repository that support it, and the specification talks about Rational XDE supporting it.

I wonder how Mr ERP4IT will think about it, as it looks like something he might be interested in.

tags: ras, reusable asset specification

byebye Borland(of old)

Just yesterday, Developer.* posted a good article on the impact of the "platform play" on the ide business. It's focus was on how development tools stagnate because ide's are part of the broader platform and are given away free these days.

And, just to hand, borland divests their ide business. Ok, they really mean winds it down. Who would want to buy a couple if IDEs in todays world?

Borland is now looking to be a Application Life Cycle player. Will this make it a more tasty morsel for Oracle?

 

traceability in event driven architectures

Brenda Michelson writes a long post on event driven architecture EDA. I've been a supporter of EDA for a while now and have seen it deployed badly and well. One thing I'd like to draw attention to is extreme loose coupling's impact on traceability. Having an extremely loosely coupled system makes some things simpler but shifts the complexity to other areas. One of those more complex things is now traceability, as Brenda mentions.

A big issue to face when trying to convince architects of an EDA system is the lack of transparency of the system. Architects fear losing the ability to know what's happened in the system. To operationalise traceability for you, here are some questions that you might get from an architect. How did this event get here? What were the chain of events that caused this event? What other events where caused by the problem event? What events do I need to compensate for now that I know there's a bad event in the system?

To enable traceability at the technical level, more information needs to exist in the header (or envelope) than Brenda lists in her "what is in an event?" section. To enable traceability you need two more fields in each event header, you need an array of ParentEventIds and an array of SibblingEventIds. You also need to be able to calculate a hash of an event to uniquely fingerprint it and it's this hash that lives in the relationship fields. Having these two bits of information allows you to navigate back to the root cause of an event and to understand all parallel events too. For example, a B2B SalesOrder transaction comes in. It's a batch of sales orders that need to be split and each sales order is put on the event channel individually. Each salesorder is transformed into a SAP idoc format, which is itself put onto the event channel. Here you can see that each SAP iDoc event must be able to be traced to it's originating B2B event.

Once you've technically implemented all these relationship keys, you need to be able to store all the events against the root event. You'll need to store them in a relational database somehow and provide a GUI for people to be able to navigate from any event backwards, forwards, sideways. As an aside, the processing applications can use the eventIDhash to log information to the event as they're processing. For example, SAP could write warning logs against particular SalesOrders if there are warnings.

So now we've solved the technical aspect of traceability, lets look at the business process implications.

The business process aspect of traceability is a little harder. There can be zillions of events in many different states. Obviously the IT group cannot deal with all the problem events. The Traceability solution needs to be provisioned to the correct business owner who can do something about the problem. In the B2B example, the group responsible for the B2B relationships will need to provisioned this GUI to allow them to investigate the issue. The GUI may also provide an edit and resubmit event functionality to help the line staff fix problems. All this doesn't obviate the need for IT support but does empower the business to manage events. Without business empowerment, event systems cannot be the all encompassing system described in this article.

tags: eventdrivenarchitecture, soa

Liferay and ServiceMix

James McGovern asks what can he contribute to a a number of open source projects. He specifically mentions liferay and servicemix, two things I've been keeping my eye on, as well as actually using liferay.

I'll start with Liferay as I've had hands-on experience with that. Liferay needs to get more open-source professional. I'm not disputing that they need to eat and have day jobs but to take it beyond it's current place, it needs better infrastructure. It needs better documentation that is free. Yes, I know the guys are writing a book. It needs someone who dedicates their life to the forums - never tiring of answering ridiculous questions. Before hibernate was assumed into the jBorg, this is how it worked. Gavin would never tire of answering my questions, whether they were high or low level. The pdf's of hibernate were very high quality.

Liferay doesn't have this. The documentation is slapdash and incomplete. Too often I've had to dive through the code to figure out how to do something. As someone investigating Liferay from a Commercial Portal experience base, I find this abhorant.

The forums are quite unrewarding too. Aside from having serious UI issues, you don't get an answer to your questions. I started getting answers to my questions only when I started slagging the forum monitors for not responding. Not good.

The focus must shift from supporting every niche appServer (glassfish - who cares!?) to getting the simple things right for people who are trying to use it for real problems.

So what can James do. Help steer them to a high quality open-source project. I understand the need to monetise it, but us coporate solution developers need easy hooks and paths into a new solution, otherwise we'll just stick with Websphere Portal Server.

ServiceMix on the other hand has a different marketing/education problem. I don't understand how it solves problems. What I need to understand is how, in relation to EAI tools such as Webm, SeeBeyond, etc, ServiceMix solves the same problems. I need to understand how I get a SAP iDoc onto the bus, or a flat-file. These are my problems right now.

I guess I'm asking for a scenario based documentation track for me to understand where I would apply JBI and ServiceMix. Being an occasional trainer I know that the easiest way for someone to understand something is as a comparison and contrast to something they already understand. That's why comparing solutions in j2ee and eai to a jbi solution would be great for different problems.

I've been subscribed to the ServiceMix forum for a good 6 months, and I haven't really gained a better apprecation of the tool. Mostly I just get build problems. No fault of the forum, just where they're at at the moment.

Lastly for ServiceMix, I need to a nice easy drag&drop mapping tool that transforms NormalizedMessages to other formats. XSLT is not part of any solution to anything.

So there, I've vented about my needs of these two projects.

tags:servicemix, liferay

Psychological biases in estimating

Michael Trumper from Intaver writes an interesting paper on Risk Management for Welcom. He talks about Daniel Kahneman's Nobel Prize winning research in which he integrates economics with psychological research. Michael takes these insights and applies them to the field of Risk Management. I'll take a stab at applying them to software estimation.

Limitations in human mental processing cause people to simplify the problem by employing various strategies to ease the burden. Another label for these simplyfing strategies is heuristics. Four of these simplifications are listed below;

Availability:
Estimators remember past tasks that are similar and relate them. This is dependent on the memory capabilities of the estimator. It's also dependent on how well the estimator understood the actual time taken by a task. Without a historical record of actual time taken for a task the software group is at the mercy of the estimator. A software group must record it's estimated and actual numbers otherwise you're left open to the vagaries of your current staff.

Anchoring:
Is the human tendency to remain close to an estimate already given. For example, saying a task will take 10 days. New information comes to hand, which doubles the effort required and the reestimate returns close to the original estimate, say 12 days. People become anchored to the original estimate.

Representative:
This heuristic refers to how the the level of information about an issue affects the perception. In estimation this can manifest in how estimations may focus on an area where the estimator has much detail, leaving other equally critical components poorly estimated. Using a formal estimation technique can force this lack of knowledge to be acknowledged and dealt with appropriately.

Selective Perception:
This refers to the phenomena of how many cognitive and motivational factors can lead to biases in perceptions. This is the where you fail to appreciate the entirity of the situation because you want meet management's budgets or performance expectations.  Because you know your manager wants to hear 3 weeks, you fail to acknowledge some aspects of the problem that will allow you meet this number.

In total, these biases exist because of uncertainties in the project. These are termed epistmic uncertainties. They can be eliminated either through better models or additional observations. In software projects there are two major ways of dealing with these. 1. Properly capture historical information. 2. Carefully tracking project information during the project. So the way to get around these psychological biases in the field of software estimating is through better time tracking and a  historical repository of estimations.

tags: estimation heuristics