Service Oriented Architecture and You
Is SOA the Holy Grail? Will it make your business more agile? Can IT actually transform an organization from within the constraints of their technology silo?
Everyone gives SOA a lot of lip service. Is it as mundane as the reincarnation of re-useable modular design of 3rd generation languages like COBOL and FORTRAN? Is it a revolutionary idea that will transform your company into an agile, lean-mean competitive machine? It should be both.
Is it a programming technique, a concept pattern, or a business process strategy? In reality, it’s all of the above. Do you consider an enterprise service bus (ESB) and SOA interchangeable? They are not, but you’re not alone in doing so. Every SOA initiative needs a service interface and many third-party vendors provide quality products, but that’s just a part of the puzzle. The concept of SOA – Service Oriented Architecture - (a consistent enterprise-wide view of corporate information delivered through common functional services) can be straight forward, but execution can be very confusing, difficult and sometimes impossible.
Are you an IT organization empowered to use technology to transform business processes?
Unfortunately, the majority of you can’t reach SOA nirvana. As hard as you try, you can only succeed at the ESB level. The problem is not that you don’t understand SOA, or that you don’t want to take advantage of its endless possibilities of consistent views across your organization utilizing shared functional objects. You do. The biggest hurdles for an enterprise that is large enough to benefit from SOA concepts is they don’t typically have stakeholders with the vision, responsibility, or political clout to see all business activities across the enterprise. In addition, enterprise architects are usually not equipped with the information needed to quantify the risks vs. rewards in a manner that the business function owners will comprehend.
Smaller more agile firms have the flexibility, desire and lack the political barriers that prevent them from putting the best interests of the organization above personal fiefdoms. Larger enterprises with functional silo responsibilities tend not share information. Sure, enterprise systems (ERP, CRM, and BI) may share processes and data values, but they don’t usually share the same data element or code. For example, customer attributes may have a single source of input from a CRM system, but the information is usually propagated to multiple independent data stores. This leads to multiple views and redundant coding to access the same attributes. Also, when a system is implemented, functional silos typically spend more time protecting the information through security role access than in meetings defining how other silos would benefit from corporate information.
How can your organization get their arms around starting an SOA-based initiative?
Begin internally within IT and build a foundation by identifying who will be your business champion and determining if you have the appropriate expertise in your enterprise architect(s). Review a few of your core business processes and identify the attributes that are stored and where they are stored multiple times. It is always enlightening to review reporting. How many different times is the same information attribute reported and from which data sources? This will identify tale-tale signs for potential services opportunities to be exploited.
After you have done a little leg work to build a foundation, you will be ready to start a formal SOA initiative by:
- Creating a business strategy with a future state of specific business processes
- Architect a solution to include requirements, policies and standards
- Create compliance and governance procedures
- Define measurable metrics for success and how they will be implemented
- Determine the tools that will be used to build the functional services
- Determine a roadmap of applications and projects that will benefit
|
