Application Architecture, Development & Integration

For those of you that might have missed it, we took a cue from all of the negative economic news/talk of budget cuts, and added a panel on cost optimization (see link for slides).  Jim Duggan, Roy Schulte and I started off by highighting a framework to categorize cost savings based on who has the decision rights for a potential cost savings action and who would be impacted by it:

• IT Procuments – IT Leaders and their vendors own the decision rights
• IT Cost Optimization – IT Leaders own the decisions rights
• Joint IT/Business Cost Optimization – the decision is made jointly between IT and business leader
• Business Restructuing and Innovation – the decision is usually made by business leaders and IT leaders have little influence

The idea is to work on cost optimization opportunities at all layers, but to pay particular attention to the areas where you call the shots and can act fairly quickly rather than fixating on things that you have little control over.

This leads to the second framework that we brought up, which helps prioritize any cost optimizaiton idea within the above structure.  The idea is to focus on cost optimzation opportunities based on:

• Size of potential savings
• Time-to-Savings
• Cost-of-Savings
• Risk-of-Savings

This is the tip of the iceberg on an number of ideas.  You can see much more content on this at our site on IT and the Economy.

Earlier today, I had the pleasure to briefly meet Malcolm Gladwell and then listen to his keynote.  He told a number of great stories that illustrated things that we should all keep in mind, particularly in the increasingly cost-cutting crazed world that we live in .

The first story he told was about the first boxing match broadcast over radio.  Malcolm also highlighted the dramatic drop in crime in New York City in the 1990s as well as the fall of the Berlin Wall.  The point in all three cases was that dramatic change occurred in a very short period of time and with very little cost.  In other words, even in times when budgets are very tight and business leaders only want to hear about business cases that return value in a matter of months, there is the potential to help drive dramatic change.  In fact, this is likely the time when dramatic change will occur in various industries.

Next Malcolm highlighted the importance of re-framing context when striving to drive change.  He mentioned that safety laws did not drive many people to wear seatbelts.  However, when children who grew up in car seats asked why their parents were not wearing seatbelts, many parents started wearing seatbelts.  The same dynamic applies to how Apple changed the context of mp3 players from techy devices that required a decent amount of geeky knowledge to fashion statements that anyone could figure out.  All of us hoping to help our organizations by leveraging IT, should stop and think about how we can change the context away fixating on devices, software, and things like viruses.  Rather, we need get people focused on how technology can help business and government change in meaningful ways.

The third point that Malcolm made was around the importance of social power that comes from people in a position to rally people to a cause.  Interestingly, the individuals who can rally critical masses of people are often not executives or other obvious leaders.  Referring back to The Tipping Point, Malcolm pointed out that people that can drive mass behaviors are often either:

• “Mavens” – experts that we all turn to
• “Connectors” – people that no many other people across social circles

Finally, Malcolm told a story around the U.S. Navy’s struggles circa the beginning of World War II.  The path to solving the challenges turned out not to be the normal options: changing leadership, throwing money/resources at the problem, finding a better expert.  Rather, it was about aggregating a wide variety of information as well as a wide variety of ‘mavens’.  This led to the identification of key pieces of information that were rapidly disseminated through ‘connectors’ to ship captains.  I’m sure there is much more to the story and that I didn’t get it all right, but the main point leads to the power of combining many different information types with a wide variety of experts and the ability to quickly disseminate actionable advice.

This makes me think about the ‘information’ part of ‘information techology’.  We shoud all spend a bit of time thinking about what information within and outside of organizations would be most valuable to help business leaders make better decisions in these challenging times.  Imagine if IT could not only help with that part of the puzzle, but analytic and collaboration technologies could help experts compare thoughts on the information, and social networks could help rapidly rally people around key actions…

In other words, we should not simply fixate on the money/budget side of things, but we should realize that dramatic changes often happen with very little money/time and we have a lot of the relevant knowledge, skills, and cheap tools that can be key to making the change happen!

Malcolm was also kind enough to sign copies of his latest book Outliers, which I am already about 1/3 through reading.  It has me thinking about what being born in May of 1968 has made possible (or not)…

The first session I attended this morning is David Norton’s “How To Make Agile Waterfall“ (click link for slides).  He just put up a slide entitled: ”Waterfall Gives the Illusion of Seeing the Future – Accept the Winds of Change”.  To me this is one of the key points when it comes to the value of agile methodologies.  Let my digress for a moment…

I vividly remember the annual exercise, which many of you still go through, where the business folks show up at the beginning of the project approval process with a huge ”wish list” of projects they would like done.  I was always convinced that if I looked hard enough at the list, I would literally see the “kitchen sink” somewhere in the list.  Of course, there was no way that the development organization could tackle even half the list, so people would go through a prioritization exercise.  Then it would take months and months – if not years – to deliver the things the business folks had so desperately wanted.  All too often, when things were delivered, the business folks said that this wasn’t what they really wanted.  This would lead to people pulling up the requirements docs and debating whether what was delivered was what the business had asked for…

The point of David’s slide is that agile methods change this dynamic dramatically.  A few years ago, I talked with a client who gathered up the annual business ‘wish list’ just as they were switching to an agile method.  Interestingly, the kept the list.  As they deliverd incremental pieces of what the business wanted, conversations where held where the business said “ok, now that I see this piece of the puzzle…here is what we need to see next and these are changes that should be made to what you prototyped…”  After delivering in this way for 18 months, the development folks looked back at the business wish list.  Less than 20% of what was on the list turned out to be things that the business asked for over all the itrerations that had been done over the last 18 months.  There were also a number of things that business asked for over the iterations that were NOT on the original list.

What does this tell us?  As many of us already knew, the business often doesn’t REALLY KNOW what they want.  David just used the term “crystel ball gazing” as a way to think of how traditional project wish lists work.  Unless you have business people that are really good furtune tellers, you should seriously consider at least shortening waterfall cycles if not moving to a real agile method.  The big caveat is that whatever you choose has to be something that the business is willing to engage in, or it will all be for naught…

Dan Sholler’s session Initiating a SOA Effort (click link for slides) did a nice job of highlighting the basic things that lead a SOA initiative to be successful.  Many people first coming to SOA struggle to understand what this concept is really all about.  He started off with a nice simple list of the key principles of SOA:

1. Modular
2. Distributable
3. Swappable
4. Discoverable
5. Shareable

From there he highlighted that the primary benefits of SOA are agility and shareability.  To that at end, he made some very clear recommendations:

• Design the interaction layers of your applications according to the five SOA principles
• Focus on reducing dependencies between volatile implementations
• Share capabilities across system boundaries

Later in the presentation, Dan made a point I really liked: “services are agreements”.  In my view, understanding this is key to SOA success.  Thinking of a service as a piece of code that you throw over the wall to a production/operations group is totally missing the point.  Rather, we need to think of a service as a promise the service creation/delivery party makes to all of the parties consuming the service. 

Looking at advanced implementations, such as the work Amazon.com has done, leads to some interesting implications to application organizational structures and work processes.  The Amazon folks have clearly stated that the same team that builds a service is also responsible for running the service.  This team also figures out how the service should evolve, prioritizing new features and functions.  With only a small hop, skip, and jump, this conversation gets to development methodologies.  Personally, I think agile methods are another key consideration to keep in mind when thinking about how to go about doing SOA.  Check out David Norton’s sessions, particularly the one “How To Make Agile Waterfall“

• People question the “value of SOA” all the time.  Just as there being good and bad relationships between people in regular life, it turns out that there are a large number of both SOA Successes and SOA Horror Stories.  The key is taking the time on the “softer issues” such as SOA Governance and How to Organize for SOA.  It is also critical to hit the “value cynicism” head on by really nailing SOA Business Cases.
• Individuals in a relationship often need to work on being more mature in general.  Application organizations need to mature in general, not just specifically for SOA.  Make sure to check out the sessions on Application Governance and Maturity
• My favorite moment was when Sue mentioned that SOA had been around for quite some time and was still having issues – just like a boyfriend that had been hanging around for too long.  Roy made a great point about how SOA has significantly evolved from the early days of basic reuse and request/reply concepts.  On that note, check out the Delivering on Advanced SOA Track and particularly the sessions on Event Processing and Context Delivery Architectures.

As a final point, the notion that every IT organization’s journey with SOA is as unique, rewarding, and challenging as any serious relationship between people is a great thing to keep in mind.  There is tremendous value here, but we do all have to work on it.  We need to make sure we are focusing our time on the right things…every day – just as therapists are want to say!

In the applications world, we love to talk about the latest architectures, techniques, and technologies. All too often, we fixate on these things and don’t think about the best way to make decisions and drive behaviors. This leads to a condition that Matt Hotle and I often call “chasing the next shiny object”, where people mistakenly think if they just bought into the latest development environment, web technologies or methodology – then all would be well. Unfortunately, chasing these shiny objects often results in another old saying coming true – “a fool with a tool is still a fool”.
For a couple years now, a bunch of us have been working hard on a maturity model that handicaps how well an application organization is governed. Matt will hit on most of the key concepts in his session on Application Governance and Maturity. One particularly critical aspect of this discussion is people and skills, which Sue Landry will tackle in Modernizing Application Staffing and Skills.