![]() |
|
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. |
|
| ||
|