The Politics of Design

I've enjoyed reading some the the Spolsky-generated articles recently, but I was snagged by the viewpoints put forth by Daniel Auger in his post "The State of Spolsky or How I Learned to Ignore my Legacy Programmer Boss". That post was furthered by Krishna over at Thought Clusters in "The Legacy Programmer Boss".

Daniel Auger says:

The Legacy Programmer Boss is the manager who had a successful programming career in the past but sees many modern concepts as language baubles, academics, and anti-patterns because they are out of the loop. The fact that they once had a high degree of expertise gives them confidence in making mis-judgements.

I wanted to focus on this concept because I believe that every programmer will eventually become a "Legacy Programmer Boss" or a "Legacy Programmer Architect". It is almost universal that this phenomenon will occur in older,experienced software professionals. It is also guaranteed that every programmer will at some point have a legacy boss lead his team. It only helps us all if we can communicate better. When you, the young turk, run into this surly skeptic, try to remember these 7 tips to help work together...

I’m so glad SOA is dead because we can move forward without the hype-anchor weighing us down, and confusing those who probably shouldn’t be muttering ‘SOA’ in the first place. This means we’ve finally crested the peak of overinflated expectations and trudged our way through the valley of despair and shaken the shackles of a new approach...and can get on with business!

Service oriented architectures were around long before SOA became a cool buzzword. A service oriented architecture is still a viable approach, but you need to right-size it for your organization. Here are some items to ponder regardless if you are just starting out, or have a mature SOA in place.


Don’t be a victim of accidental SOA architecture:
Have some idea of where you want to end up before starting your SOA journey. If you’ve already started you still need to determine your ultimate end-state. Too many companies embark on this journey before understanding the true costs, what role governance plays, what packaged apps are required along the way, and how long they are we willing to take before getting to their destination. This lack of planning is analogous to uprooting the family, committing to a new job in an unknown location just because someone showed up at your house and handed you keys to an awesome new sports car...you don’t know were you’re going or when you are going to get there...but you’re making great time!!!

Find (or define) an SOA maturity model:
Creating a roadmap or referencing an SOA maturity model will help you determine the ultimate end-state of your SOA. Check Google for a maturity models that fits your needs. If you don’t like what you see (too vendor specific or too complex) create your own! The real value is in the conversation among the various impacted parties and the confirmation of your end-state including how long it could take to get there.

SOA Maturity model - items to consider:
1. Not every company needs to achieve the highest maturity level. Pick the level appropriate for your company.
2. Advancement is not linear. You could spend years in one phase then blow through another in a matter of months.
3. The gap between phases could be larger than you realize. It could take substantial investment to get to the next level. Be patient...see #2.

Consider your environment - Size matters:
One of the most important drivers to right-sizing SOA is your environment. Size matters when it comes to getting traction with an SOA approach. If you have large disparate legacy systems, or your company has grown through large merger / acquisition then you have large challenges to solve and your company is more likely to undertake large investment to support these systems or solve these problems which will move you up your maturity model more rapidly.

On the other hand, small and medium businesses need to carefully choose which SOA stepping stone to chose first. Many vendors would tell you that you need a runtime governance tool to monitor service performance, determine the services largest consumers, etc. However, an investment of this size early in the life cycle could delay perceived business benefit and kill your SOA initiative before in becomes an integral part of your landscape.

Also consider your business model. Are some areas of your business more stable and consistent than others? You may want to target these for some of your first services rather than an area in a great deal of flux.

SOA does have its place as the core architecture that supports your business but it is not something you can buy off the shelf and plug in. It will not be successful without significant architecture influence on how to right-size it for your organization.

One final note on selling your next set of SOA investments is...don’t mention SOA. Focus on the business drivers for the need and how SOA enables the business. Focus on the problems it solves. SOA is the means to the end, not the end itself.

Has SOA been successful in your organization? What were some of your largest stumbling blocks? Bring the comments! Good or bad, I’d love to hear them!

photo: Mojocesa

We have all been searching for a concrete and measurable return on our SOA investments. We've searched the internet and read case study after case study. Industry experts and SOA pundits tell us that it's there. We know in our hearts that it's there. However, we've all been in the meetings where business stakeholders and executives are not satisfied with what we believe or what the experts say. They want us to prove Service Oriented Architecture has a definitive and measurable ROI. It's an elusive problem. How do we prove to them (and to ourselves) that the proposed architecture can pay for itself?

The situation is common. Adoption of the new architecture has been slow (or non-existent). If you are to hit your roll-out targets, you have to find a way to accelerate it. But for some reason, no one seems to be picking up your latest advancement and rushing headlong into a new type of implementation. At the same time, no one provides any significant reasons for this reluctance. The feedback does not call out weaknesses in your design. In fact, the little feedback you've received was positive. It's just that they choose to roll-out new functionality using the old, tried and true approach. Since you have spent the majority of your time nurturing this new architecture, you are personally invested. Your frustration starts to build as you see opportunities missed and weeks pass. After some time, it begins to feel as if the reluctance is just an unspoken, negative judgment of the new stuff; of your new stuff.

In fact, the real reasons that the adoption is slow has very little to do with the architecture at all. The slowness is understandable and you really should have predicted it.