Please See Paul Holland’s Original Post Here
The following is a response sent to Paul via Email on his blog.
Paul,
I took a look at your blog, and I like the concept, as well I am very passionate about the paradigms of technology refreshment.
I had some thoughts about how to extend the idea, but first I want to take a second to explain how I think about things like this. When I find a concept that I like, the very first thing I do is put my “Negative Nancy” hat on. This allows me to see all the risks, issues, holes, and otherwise negative aspects of a plan or solution, the end goal being to see these negative items before the client does, and enhance the design to account for them. When Negative Nancy turns up nothing, that signals a good design.
The point of that explanation was so that you don’t think I am being critical of your idea. I actually really like your idea, and think concepts like it are critical to some of the goals I would like to see the industry as a whole accomplish.
Some of your comments hinted at this, but as far a potential risks or issues with the concept I see the following:
Issue: Fear of Requirements Analysis Paralysis from SOA implementation
Your comments hinted at this, some organizations have such a twisted matrix organization that the process of entering into a requirements process or the required meetings is something to be feared. This issue also pops up in organizations where the executive stakeholders have little or no experience in the actual technical details of the project. That is not to say they are not experienced, in fact it is usually their wisdom that the solution must draw the from the most.
This can be all the achilles heel the competition needs to be able to “bunny hop” over you in the innovation department. If a company cannot evolve, it will be left behind by the competition and if a company can’t not evolve efficiently then it is only prolonging it’s demise. This become almost tragic when that company is the leader of the pack, and someone comes from behind and hops from behind them to in front of them.
Business moves quick these days, and as transmission speeds and methods increase combined with the diversification of the information consumption channels this speed is only going to increase. This effect is only magnified by the Globalization trend, now companies wishing to stay competitive must be aware of threats not only from there own backyard but the entire globe. Companies wishing to survive must embrace evolution, and ultimately master it. The companies that become complacent or refuse to evolve will be left behind.
Issue: Net Increase in Overall IT Risk
Some critics of your plan, will say that you are only prolonging the process of upgrading. Thinkers from this corner of the industry will argue with you that this solution only prolongs the process of actually upgrading, that is a more of a move to side, not a step forward. And that this lack of actual upgrade to the infrastructure means are still left with the same inherent risk of using outdated platforms. Further because you are adding critical infrastructure that depends on a platform with risk, that that risk is now inherit in the new solution as well.
The good news with this argument, is that they are exactly right. Don’t worry, I’ll explain why this is the best thing that can happen to you in a second.
Issue: Lack of Control over SaaS/PSaaS Vendor’s Roadmap
Along with those same thinkers are the folks who say that PSaaS are dangerous, because the company does not have explicit control of the neither the data that the PSaaS holds or has good visibility into the roadmap, or the changes that the PSaaS will under go during the foreseeable future. This comes from a conservative school of IT thought that focuses on total control of every variable is the only way to maintain any real predictability.
In order to overcome these potential roadblocks, we must climb into the our palace of pure thought and see our forest as a forest, and not as a collection of individual technological trees. On a conceptual level each of our issues stems from not seeing the modernization project for what it really is, the modernization of process. Our first set of naysayers told us that utilizing SOA to modernize is just buying time, that we are still left with the inherit risk of using older platforms.
Well, they are exactly right, and used correctly this can be one of the biggest sources of efficiency and savings in a modernization project. First we must move up a level and identify what the core business function that our legacy platform serves. Since actual business process evolves at a much slower pace than technology, many times we find modernization projects that have a short expected lifespan. These processes might have been designed to support legacy business processes that are coming to the “twilight” of their lifespan. Once we identify these twilight processes, we can easily implement SOA to just extend the lifespan of the existing (and tested I might add) legacy platform to a point where the underlaying process catches up with the already outdated legacy platform. The savings and efficiency gains are made from identifying these processes early, so that resources given to the processes equal to the expected outcome.
That leaves with another portion of business processes to worry about, the ones with no foreseeable end or processes that will always exist no matter what like accounting or billing functions. This category of processes are the ones that should be upgraded totally, but only when needed. By using your same SOA methodology as a method to buy time and remove the business urgency of the modernization, these upgrades can be done without the pressure and urgent deadlines normally associated with them.
In addition if done correctly, the SOA treatment of our first group of processes (the ones that will soon be outdated) can be used as validation of methods and design practices, so that the design of the core lifelong services can be that much richer. This approach lends itself well to your idea of creating a council to over see this modernization.
In my time as Director over a Development group, I used to liken requirements to a 4 year old eating brussels sprouts. You know it’s good for them, they know it’s good for them but they still won’t eat them. This the exact situation you get into with Requirements discussions as well. I always assumed it was just “how it was” until I saw what the Dutch did.
I was lucky enough to spend some time in Amsterdam, and I was amazed at the process by which the Dutch did business. The Dutch believe that every person has a right to have their opinion heard, and that only through the collective voice does a viable solution appear. I was willing to try it, but was very unsure of what to expect from it. To my surprise it worked, really well. The Dutch Firm took careful note of everyone’s input, even the input that sounded ridiculous at the time, once collected the input from the technical stakeholders as well as the non-technical stakeholders was examined on a level playing field. In this case an old fashioned card sort, the result was an almost painless requirements process that took 25% of the time I would have budgeted for here in the States. And the end solution not only functioned exactly how the technical stakeholders wanted, but non-technical stakeholders got exactly what they were expecting and thus the acceptance process was dramatically cut as well.
This same methodology can be harnessed in order to jump the roadblocks presented organizations that are fearful of requirements gathering. In the past I have worked with my clients to turn requirements gathering into a linear process, instead of an event based process. If done correctly companies can harness this wave and use it’s energy to help drive the solution forward. To accomplish this all we have to do is level the playing field, that is to say that requirements, features and bugs of a platform (legacy or not) must live side by side with each other on the same conceptual field. This can done as simply as using cards as the Dutch did, or more advanced web interfaces. This allows all stakeholders to easily see the entire breath of a solution.
In order to ensure success, I would see proper management of stakeholder input as the first prime directive of the LPaaS organization. Setting these procedures in place will allow that organization to farm the edge you mention for new ideas, or more efficient and streamlined methods. This will in turn trickle down into the solvency of the solution, and give the solution stakeholders piece of mind about the longevity of the modernization.
Our final naysayer tell us that we are adding inherit risk because we don’t have control or visibility into the SaaS/PSaaS vendor’s roadmap. Much like some of the other naysayers, this the whole point. By utilizing SOA, we are in a de-coupling our infrastructure into a more horizontal fashion, rather than the more traditional vertical stack. A prime directive of the architect of the SOA modernization will be flexibility, both for today’s business processes, and tomorrows. This flexibility comes as the reward for all of our previous efforts, the leveling of the playing field, the capture of the non-technical stakeholder wisdom, and the communication pipeline to the edge all come together here as flexibility in our solution.
This flexibility gives the solution enormous solvency, and allows the solution to evolve with ever the market throws next.
If done correctly, one should be able to implement these types of solutions at record speed, with very few bugs or hiccups at deployment. Keeping everyone on the same page, also allows for very effective use of non-visible partners like ODC (Offshore Development Centers) resources.
Sorry to be so long winded, but your blog really got me thinking. Looking forward to our session on Tuesday.
Greg
Greg Chambers
President and Creative Director
Opus Quadratum Studios
Greg.Chambers@opusquadratum.com
http://www.opusquadratumstudios.com
http://www.linkedin.com/in/gregchambers
Si Opus Quadratum vis, angulos praecidere noli…
