Tom dot Evans at
Abstractions dot com

Profile

Architecture Topics
- Service Oriented Architecture (SOA)
- Future Topics

References
- Software Design
- Christopher Alexander's Patterns
- Software Patterns
- Lightweight Methods

Architecture & Object Technology Links

Free / Open Source Software Links

Twin Cities User Groups

Service Oriented Architecture (SOA)

SOA..OK, but will it pay? For what purpose would we do this? Did I hear this story before?  Object Technology, Reuse, ROI,...Well, as part of the early adopters for Object-Oriented software, we sold a lot of new concepts based on ROI for reuse.

So, um, ten years later (20 for a few), how's that reuse?  Not so good you say?  Having trouble fitting that c++ code into your Java framewor...oh, doesn't fit your .NET framework very well either?  Is the code still running? Yes?  Over there?  Good.

Of course it is, legacy code in the enterprise is pretty tenacious.  I know of literally millions of dollars of legacy Smalltalk code going strong in more than one large enterprise...IT portfolio management would like to not maintain a technology with limited support in the current market place and has again announced its plan to sunset and replace the code....Big, expensive, business impacting job.  Might happen. To what forward looking business benefit? 

SOA can help with enterprise level reuse, wrap & replace legacy strategies, and business agility.

SOA is a systems or object-oriented approach to looking at software assets within an enterprise and applying abstraction and design at the enterprise level to support enterprise goals for efficient use and for fostering business adaptability.

SOA is opportunistic.  It says to a business area, understand the capabilities you deliver to the enterprise and determine the (automated) services you need to provide that capability.  Become ownership-agnostic about those individual services while excelling at the capabilities you are responsible for. 

SOA is opportunistic.  It says to IT, keep code where it is already deployed, supported, and working.  Provide a standardized, fairly easy way to reuse it as a service, vs reuse of code as an additional implementation and deployment.

SOA is business driven. Provide access to your facilities as services to other business areas with distinct responsibilities but similar needs for automated services. 

SOA is good defensive engineering. Use SOA to build a thin facade between the service requestors and your internal implementations.  Retain the freedom to refresh the technology you own with out disrupting your internal clients...you know, the ones to whom you can't say "No" to, but really don't want directly accessing your production database and making it impossible to roll out a new update :-).  This separation works well within the owning business area too.  However, like most things with the word Architecture somewhere nearby, the cost is now (and mostly local) and the benefit is later, and broader. The funding math can be a challenge.

SOA is business driven. Ask for help from other business areas - not to take responsibility for your capabilities and processes, but for some of the task level tools they happen to already have that traditionally you would be duplicating. Working together saves costs and builds in internal consistency (Think Sarbanes-Oxley).

SOA is good defensive engineering. Just don't hardwire your processes to technology.  Ask for a facade to allow for the possibility you might just be getting your needs met by some other technology next year (maybe located in a different business area) and you would rather not have to rewire your business facing systems when another other group needs to refresh technology (or gets sold or...)

SOA is independent of business boundary type and scale. 
 - Share services within an enterprise application architecture. 
 - Share services within a business area.
 - Share services across business areas or business units. 
 - Share services with external business partners, and your partner's partners.

Need to unplug the legacy code?...but it is so entrenched in so many processes you don't know where to start?  Start with a business driven SOA Model of the business areas that consume the services it provides.  Add an SOA/Business Infrastructure Model of the transactional information it is responsible for. 

Divide and... Consider building out Service facades to become the indirect touch points for the mainframe's clients. This lighter weight step creates implementation flexibility with no or limited future business processing impact.

...Conquer Now, for individual mainframe provided services, re implement those service functions where business priorities dictate a need for something newer,  better, cheaper, faster, etc. 

Need to be able to turn on a dime?  Are you basically in the same business you have always been in, but now you retool your customer facing business processes every six months or every six weeks?  Need to touch more systems than you can afford to change (in time and money)?

Separate the parts that have to change constantly (process capabilities) from the piece-parts (functional and information services) of your emerging Service Oriented Architecture that are fairly stable.  Simpler systems focused on specific process needs will be easier to change and easier to make business-time confurable.

SOA is hard.  Sharing is hard.  It requires cooperation.  It requires commitment to engage and commitment to sustain a defined level of support.  It is what your competition is doing internally and with their partners.  The do-it-all-myself because it is easier to be in control mode still works - if your competition lets it.

So Start Opportunistically...and let struggles teach you and successes pull the process along.  Drive it from the business.  Refreshing existing business systems "as is" is not an IT cost reducer. The future just might be about getting to new business faster.