Click to Play

Connecting With Customers Online
Customer satisfaction is quite important. Unfortunately, it's also hard to quantify, but to help with that, Greg Links, a regional manager at ForeSee Results...

Recent Articles

Flow Of Communication Using The Salmon Protocol
Salmon Protocol is actually one of the most exciting things that will be used by Google Buzz & theoretically could dramatically make huge changes to the way communication flows around all kinds of...

Verizon's Rollout Of 4G To Create New Opportunities
4G wireless service should be available later this year courtesy of Verizon, according to one of the company's executives. And for businesses, that could have...

Increasing Both Agile And IT Service Management...
With the increasing prominence of both Agile and IT Service Management in current IT-related discourse...

WSO2 Introduces Its New Middleware Platform
WSO2 - the open source SOA company with offices located in USA, UK and Sri Lanka - earlier this week made three announcements introducing its new...

Securing Private Analytics Data To Mitigate The Risks
With both large real and hidden opportunity costs associated with evaluating, implementing, and learning the quirks of a new analytics tool, it only makes...

Costs Between Proprietary And Open Source...
After my previous post "Cloud to boost proprietary software use?", Tim Bray asked whether the pricing comparison of "WebSphere/SUSE vs. JBoss/RHEL...


03.16.10



Building The Correct Size SOA For Your Business

By Mike Kavis

I am working on my second enterprise SOA implementation in the last 4 years. The first implementation was at a medium sized IT shop of 200+ people. That project was driven by the need to revamp business processes and leverage SOA to connect new user interfaces driven by workflow to old legacy systems. My current SOA initiative is quite unique. As a startup we are building from a blank sheet of paper.

There is no legacy to deal with.  Our biggest challenge is balancing time to market and limited resources with the desired future state roadmap.

Most SOA initiatives you read about look entirely different than the two I mentioned.  The norm for SOA usually consists of a very large organization and often times that organization is distributed across locations and even countries.  Whether the SOA initiative is occurring at a large distributed organization, a medium sized organization, or even a startup, the principles of SOA remain unchanged.  What does change is this:

• Amount of legacy systems to deal with

• Amount of organizational change/transformation that must take place

• The complexity of governance model required to enforce best practices

• The amount of politics to deal with

• The agility of the organization (or the potential for agility)

• The amount of capital available


As I look at these variables, I ask myself, "Is a Service-Oriented Architecture harder to implement in larger organizations than in smaller ones?

The two biggest SOA killers in my mind are failure to deal with organizational change and the failure to implement an effective SOA governance strategy.  Basically, people are the problem, not the technology.  So if there are less people to resist change, and more self governing due to smaller IT teams, doesn't that make it easier for smaller organizations to apply service-oriented concepts?

I can't speak for the bigger projects, but let's compare and contrast the medium sized shop experience I had vs. the startup experience I am currently working on:

Legacy

Medium size company - This company had many silo systems built with various technologies, both proprietary and with commercial products.  Some systems already used web services and some did not.  Data was replicated across multiple systems and the complexity of integrating these disparate systems were high.  The immediate goal was to get many of these systems to integrate, which SOA can help with, but it is not the ultimate value proposition of SOA.

Startup - Nothing exists.  We start with a blank sheet of paper and can build it right from the start.  The biggest challenge is balancing getting a product to market versus how robust the architecture needs to be.  We decided to start first with data services and eventually move up the stack.  We are now just starting to work on the business process and rules layers.

Organizational change:

Continue reading this article.


About the Author:
Mike Kavis is a veteran Chief Architect with over 23 years of IT experience including distributed computing, SOA, BPM, data warehouse, business intelligence, and enterprise architecture. Read Mike's blog at Enterprise Initiatives.
CTOupdate is brought to you by:
SecurityConfig.com NetworkingFiles.com
NetworkNewz.com WebProASP.com
DatabaseProNews.com SQLProNews.com
ITcertificationNews.com SysAdminNews.com
LinuxProNews.com WirelessProNews.com
CProgrammingTrends.com ITmanagementNews.com


About CTOupdate
A collection of Articles an news designed to keep professionals in the tech industry informed about the latest developments in an ever changing landscape Tech News and Updates for Tech Professionals




-- CTOUpdate is an iEntry, Inc. publication --
iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509
© 2010 iEntry, Inc. All Rights Reserved Privacy Policy  Legal

archives | advertising info | news headlines | free newsletters | comments/feedback | submit article



Tech News and Updates for Tech Professionals CTOUpdate News Archives About Us Feedback CTOUpdate Home Page About Article Archive News Downloads WebProWorld Forums Jayde iEntry Advertise Contact