In a previous post, I had mentioned that I had, in the past, been a product manager for IBM. Well, my title is now “Solution Architect”. Sounds fancy, right? It may be interesting to note that, with the size of IBM, I have discovered that there are other “solution architects” out there who do different jobs… So the only talk about is what I do…and then probably not in details.
So, my job is to investigate a particular area/domain and to come up with a way to use out tools in that space. In particular, I am currently looking into the (very broad) domain of governance, risk, and compliance. In this domain, I have to answer the question: How can IBM Rational tools be used to help our customer better plan, define, enable, and measure a software (and systems) development governance infrastructure? Exciting, isn’t it?
So what is governance? Well, back in June, there was an announcement from IBM that defined it as:
- Establishing chains of responsibility, authority and communication to empower people (decision rights)
- Establishing measurement, policy and control mechanisms to enable people to carry out heir roles and responsibilities
I prefer to reduce this definition to:
- Governance is the process of specifying, deploying, and managing decision rights, measures, and controls.
- Make sure the right people do the right thing at the right time.
OK…that last one might be oversimplifying things…thereby breaking Einstein’s rule! And of course, software development governance would simply be these definitions applied in a software development organisation.
Now, we have a pretty good idea on how to use our tools in the management of the software development process. The question then becomes, how do we help our customers set up this environment? This is a question that is beyond the scope of this blog entry.
So how is this different from what I used to do as a product manager? Well, I am no longer concentrating on a single product, but on a usage pattern for a set of products. Asides from this, I am still looking at the products (plural this time), creating usage scenarios, and writing requirements.
And in fact, I have not even bothered changing my business cards that describe me as a product manager.
So Kelly, does that meet your needs?