I ticked the wrong box

The types of companies I (used to) work for and (now) consult to,  love release management.  At least their IT people do.

For those who are not in the know, check out the following 2 resources for a bit of background

• http://en.wikipedia.org/wiki/Software_release_life_cycle
• http://en.wikipedia.org/wiki/Release_Management

When companies often start out, they focus on getting IT systems enhanced as soon as possible.  A simplified, but common cycle is design (maybe), build (definitely), test (should) and deploy (definitely).  Steps in this process may be skipped when an organisation is small, and the side-effects of getting something wrong in build or deploy can be handled on-the-fly.  As companies mature and grow (in both size, application complexity, and IT landscape complexity), they often wish to have more control over the processes that manages software design, development and deployment.  As enhancements start to involve distributed application development (eg, introducing a new feature on a customer care system, that requires a service on a billing system, and have that exposed by an integration bus, and that integrated with from a web or IVR channel), the process and dependencies involved with deploying that application become more complex.

To ensure that the cross system (and often) cross department, company or country design, development, test and deploy process, companies introduce Release Management Processes.  Different application development projects are collected together, and managed from a central point – who is unimaginatively known as the Release Manager.  The release manager usually has responsibility for delivery and deployment of all the changes requried within a system, and across systems for a particular instance of deployment activities (that’s a wordy way of saying that a whole load of stuff gets developed, tested, and then deployed together).

So, to recap – early days – applications designed, developed, tested and deployed whenever people want.  More mature business – applications designed, developed, tested and deployed under a managed process, with defined implementation dates.  In principle, that sounds fine.  In fact, it sounds like a sensible way to manage development and deployment.  Software can be complex, and complexity grows as you have more systems involved, different parties, different skills, and in some extreme cases, different countries and cultures.

Business users (ie, the people paying for the development, and specifying the functionality) rarely like release management.  It’s costly.  It’s slow.  It’s inflexible.  And this is more true if the business users know a little bit about software development, and especially if it involves the web.

The web is known for being an inherently agile environment.  Web applications are usually self-contained and loosely coupled, and can be easily and quickly altered.  There are other types of applications that exist in enterprises that do not have the same inherent agility.  Customer Management Systems, Billing Systems, Banking Systems, ERP systems.  All of these systems usually have long lead time on changes, strict testing requirements, are have historically been designed and developed in a different (monolithic) manner to web systems.   The requirements on them are often different too – they often aren’t about exposing new “services” to the public, but more about internal services, bug fixes, operational fixes, or enhancements to allow new products to be offered.  However, they don’t interface with the external customer and often aren’t driven by the same requirement for agility – it’s often easier in business (for your brand, and bottom line) to deploy something that is a bit crappy internally (manual processes, double-keying data etc) if you can get the message out to the customer.

Business users want the ability to alter the messages and functions that are delivered to their customers on their terms – when they want – not bound to some (in their eyes) arbitrary release schedule.  They don’t understand why their functionality must be deployed with another, completely unrelated, system or process.  They want to get their product to market.

I feel strongly that certain types of systems fall nicely in a “release managed” category, and others fall into a “system owner” managed category.  (sidenote: I feel that for a platform that supports as much functionality as “the web” that often The System is too coarse a unit for splitting – it could be taken down to business process, journey, or user type).  For me, I believe that systems that have a requirement to be highly agile, provide a high level of flexibility (configuration/scripting, as opposed to packaging and release of compiled code), and support essentially decoupled functions and flows, should not necessarily form part of conventional release management processes.  The “release early, release often” convention can be followed on these systems.  Obviously, a business must be made aware of the risks with this approach (e.g., more defects are likely to arise), and they should also be made aware of some of the sensible processes and changes in methodology to make this approach work (e.g., agile development methodologies).  In my mind, integration and web implementations fall into this category.

Integration systems enhance the ability for each system to remain decoupled from it’s peers – and this in turn means the systems are more modular, and should be able to support development and implementation (outside of a monster sized release), even when all of the required functions are not implemented.  Integration systems can provide stubs that indicate a service is unavailable, and when each system is finally ready, then the processes can be turned on in each.  Integration systems are inherently cross application, yet system independent at once.  This paradoxical view on integration is what makes them great candidates for exclusion from release cycles – they are self contained, but support both the situations where external systems are present, as well as when they aren’t.  This level of resilience and flexibility means that they are a core enabler to allow other systems to deploy functions, and still work when the up/downstream systems they are reliant on do not exist.

I have a couple of recommendations if your organization is considering looking to migrate to a release management style approach for application development and deployment:

1. Applying release management only to systems where it makes sense to do so, will allow a business to maintain the necessary rigour required for financial, legal, regulatory, professional and moral obligations.  Release management should not be a one-size-fits-all approach.
2. Shielding systems with integration and process configuration flexibility (on/off switch for process/service enabling) will reduce the dependency of each system on it’s peers to be launched – and this in turn increases the flexibility to make changes to an individual system without them having a downstream impact, and increases the ability to more quickly make changes.
3. Applying a finer-grained design, build, test and deploy scope (i.e., not cross-system) to customer facing systems will give businesses the agility they desire to get their messages to market.  This in turn will allow businesses to try more products and services in the market, and respond to competition in a more timely manner.

I believe following an approach that ensures that your systems are shielded from changes in each other, and promotes flexibility and agility in the customer facing systems is key to delivering true value to the business in terms of both responsiveness, and reliability.

(reposted from my entry at allconsuming.net)

I’ve got an issue with one of the fundamental premises in this book. The book asserts that the future potential business value of a company can be measured by determining a ratio between market cap (number_of_shares * share_price) and revenue (at least I think it was revenue!). And I believe this is a generally sensible and applicable approach. The rationale that is used is that investors understand a companies business model, and can see future benefit in the company, so they are willing to pay more today, for expected future returns in the company (the whole NPV of investment thing).

Now, this premise presupposes that investor actually understands and analyses the businesses model – and that is not always the case. Many investors do not perform the due diligence involved to look at business models, and often invest in industry they don’t understand, because of a “bandwagon” type effect. I can see that this effect could also be accentuated by people using momentum investing, or pure technical analysis. They would drive up prices of stocks, when a business may not have a sustainable model.

This book was written in 1997 (I think), and I wonder if the author would refine his theory if this book was written now given the .com boom and bust. Lots of business, with a high market cap, and no future earnings. Suddenly people thought “WTF are we investing for? There’s no sustainable model here?!” and the market fell over.

I’d be interested in others thoughts on this….

(I wrote this on the plane, so things are slightly out of order on my blog…)

I’m sitting here on QF190 in business class on my way to Sydney. I’m reading American Psycho by Bret Easton Ellis. I love the style of writing in that book. The level of description for objects of desire and disgust in that book is astounding. I thought I might write the rest of this entry in a similar style – if you have read the book or seen the movie, let me know what you think. If you haven’t, you should. Don’t think I’m an arrogant mo-fo from this post until you have, and understand the style

I did not spend any time in the first class lounge as I ordinarily would as I was spending my time with AMC in the airport, talking. I also discovered that I am arriving in the UK 3 days before my entry clearance is valid. That sent me into a panic for 5 or so minutes with associated hot flushes, until we went to the Qantas ticketing counter and talked to the lady there. I didn’t get a good sense of reliability from the advice she offered, which is why I’m going to get Qantas to check it all out from the First Class lounge when I arrive in Sydney. They already provide me with a greater level of trust than the ticketing counter lady, even though I have not seen or asked them to look into it for me yet.

I was the 3rd passenger onboard the plane. When I arrived in the departure lounge the plane was not boarding, even though the television screens said that it was. I find that very frustrating. I could have spent more time with AMC had I known that the plane was not _really_ boarding. When they called the business class, platinum and gold Qantas frequent flyers, and the One World ruby and sapphire (I think) club members, I had had enough of standing around and boarded instantly.

After I had been on the plane for around 10 minutes, I was pleasantly surprised to see that the business class cabin was sparsely populated. I always like _not_ sitting next to someone whilst I’m flying, and as a platinum level frequent flyer _and_ paying for a business class ticket they _never_ put me next to someone else, unless the plane is full. There is one familiar face on the plane. I do not know his name, but his face is familiar from the First Class lounge from back when I used to fly to Australia weekly. I was then offered a tropical fruit fusion, a water or a champagne. I decided on the champagne, as I always take the champagne on a flight, regardless of the time of day.

There are 10 people in the cabin. The capacity is 30. 4 of the people are a party of 3 women, and a baby. The baby started screaming on takeoff, which always frustrates me. I expect to hear that back in economy, but not in business.

The hostess after take off came around and offered drinks. My second drink on the plane is always a G’n'T. This Qantas flight stocks Tanqueray London Dry Gin, which I enjoy. It is not the number 10, but even the entry level Tanqueray is a good gin. I decided on a small bowl of olives over the roasted assorted nuts as a snack. I enjoy the taste of the olives, and have not had them on a plane as an in-flight snack before – they must be a new addition the the menu. After the gin and olives, the meal service arrived. The choices were a Thai Style Yellow Chicken Curry with Steamed Rice and Asian Greens, a Salmon Fillet with Herb Butter and Chat Potatoes, or a Salad of Roast Lamb with Chickpeas, Red Pepper and Tomatoes. The first two items were served with a Peking Duck and Cucumber Mint Salad, and the Salad was served with a fruit salad. There bread choice was a wholemeal or white bun. I was drawn by the Thai Style Yellow Chicken Curry with Steamed Rice and Asian Greens, but eventually decided on the Salmon Fillet with Herb Butter and Chat Potatoes. I felt like fish over Thai Curry, probably because I had a Thai Green Curry for dinner last night. When the meal arrived, I had the Marlborough Sauvignon Blanc. The salad dressing was too spicy for the meal, and the broccoli was a little overcooked. The peas were excellent, as were the potatoes in the Herb Butter. The salmon was to die for – I have never had such a good aircraft Salmon. Dessert choices were a Selection of Seasonal Cheese and Dried Fruit, Ice Cream with Almond Biscuits, or chocolates. I always take the cheese over ice-cream. The platter consisted of an above average cheddar, and an average Camembert. The dried fruit was _an_ apricot. There was also a cube of quince jelly, which I enjoyed. Then I had a 10 year old Penfolds Port, which was of average quality, a coffee, and a macadamia chocolate.

I also drank 3 glasses of water as I need to keep my hydration up because I have been dehydrated over the weekend, and 27 hours in an aeroplane is not good for you.