The Enterprise Architect's World - Episode 57

[Former Member]

Intro:

Creating a SOA roadmap, with not just SAP in the picture, is a long term commitment towards organizational commitment. The journey to SOA can rarely be seen as a uni-vendor approach in creating a series of activities moving towards an organizational commitment towards SOA is not something many IT Organizations can achieve on their own. Not many IT Organizations within a customer environment is powerful or influential enough to achieve the same. Therefore, the need for trusted advisors in the market that provide the necessary ammo to equip such IT Organizations with enough ballast to ensure that the CIO is elevated to a state that business sits up and takes notice. One of the classic deliverables achieved through SOA Workshops. While in the process of achieving the same, decisions need to be taken that are not only influenced by business or technology alone, but also by the political climate within the organization. An approach that avoids this nasty face-off for all Enterprise Architects. A starting point for the same is enterprise-wide data models that are built on the basis of business requirements, made process centric by the use various techniques and ideas that come as proprietary approaches of System Integrators. This process-centricity plays upon the various organization dynamics, rendering enough and more importance to those supreme business stake holders, who own and fund such IT initiatives, and therefore the process-centric approach with SOA actually can help drive its adoption. Not every approach can be scientific and logical, right? We live in a world of people and unfortunately for us, most of them hate IT. In order to ensure that business visions are realized through SOA, it needs a different approach - till a time comes when SOA adoption isn't such a huge challenge anymore.

Typically, a good starting point for SOA initiatives can happen when Enterprise Architects start scouting around for such showcases from a value chain (supply chain + demand chain) perspective. When broken down into business partner relationships 
at a granular level, this provides any consultant worth his/her salt to look for such starting (read scratching) points as though they were buried treasure. Such a level of superimposition of granular processes with "SOAble" processes can become the inflection points for driving disruptive innovation within an organization without upsetting a stable core. Defining the Enterprise Architect's approach to SOA:

Mile 1: Start with a SOA Workshop

The organization may not be new to SOA at all, on the contrary, it might be filled with a bunch of SOA experts. And that is exactly where the trouble begins. The EA centricity from the past and current within an enterprise makes the entire bunch of Enterprise Architects within the IT Organization so aware of political equations and "technology myopia", that it is in the best interest of any organization to bring in this fresh perspective from outside, with folks devoid of any kind of allegiance or leanings. And probably, more experience across multiple customers to bring about a little bit of an awakening. (The very reason for the existence of an SI)

Mile 2: Start with the BPX Centricity

Start the initiatiatives from a top-down approach - not from an overly superficial Business Consulting flavor, rather the "feet-on-ground" approach of a BPX, to break down processes that more or less are horizontal in nature, with few variations. 
Every organization likes to believe that they run the most complex business, processes, implementation, IT landscape etc. which more or less make the "noise-makers" trying to convert exceptions into standards. And this is more a mind game. Not  something IT or Business consulting can achieve on its own, as a standalone. This world belongs to us - the BPX, the Enterprise Architects. It is the revenge of the nerds. Suffice it to say, every process can be broken down into its logical set of building blocks, be it O2C, A2D, H2F, D2F so on and so forth. This can be looked upon as the conceptual model building blocks with the context-neutrality in place, that just yearns for context-sensitivity in terms of industry, geographic and other such context drivers to bring about the business flavor in terms of business processes, yet at a layer of making a logical sense out of the entire exercise to create this decomposition of business processes to be assembled and extended as the logical model of data objects. The way an EA would extend any Object-oriented model from the conceptual to the logical realm. Let us take procure to pay as an example.

Mile 3: Identify the Value chain link

If you are in a position to take along such influencers (who come with a certain amount of rigidity and mind-block) along with you through Mile 1 (an iterative approach is very useful here), the next Mile is to create the business process 
awareness with such decomposed elements to be broken down as modules or clumps of functionality that would bring about this paradigm shift. This is one point where you may note the toning down of the sound bytes and detrimental noise in order to 
help you move to the next level of Business Users, owners and stake holders. In this mile of the journey, you would note the package leaning - it could be a bunch of folks rooting for and against SAP or any other package. This is the place which 
requires a careful handling of events of reaching upto a level where you are in a position to break down a particular application, decompose it into its logical set of functions, map the road ahead in terms of ESOA adoption, increased functionality, statement of vision and many other such parameters that would provide you with a thumb-rule estimate on the level of customization (read damage) that may be required to make the required packaged application "work" in the organizational context. And this would provide you with a level of granularity which would provide you a basis for creating your own Enterprise Services. 

Mile 4: Applying a framework

To define the future state of any organization on the SOA journey will need to best support the organization's business strategy by bringing together Business and IT strategies on a level of common understanding that the information exhanged 
between them is fairly context-neutral and extended in terms of the business process being addressed by the underlying IT initiatives. This can only be possible if there is a framework that is adopted, found useful to bring together the processes, technology and the overarching SOA Journey. Zachman, FEAF, TOGAF, Gartner etc. and a bunch of other frameworks exist today to make this transformation journey an extensible one. If the SOA Journey being defined by IT be in a position to bring together business processes, Enterprise Service Infrastructure, Information access with a set of rich Enterprise 2.0 tools like RSS, Facebook, LinkedIn, Widgets and other such Web 2.0 technologies in place to create an orchestrated initiative around SOA to create business value, the same has a higher chance of acceptance and drive toward SOA adoption. Process-centricity and mapping brought together and equated on par with roles, work and control centers would provide a logical composition and decomposition of sub-processes to arrive at the granularity of the enterprise services being sought to weave the fabric of the underlying application made useful by a business process.

Mile 5: Doing the Math right

While adopting a framework and creating the underlying business fabric weaved together by the Composition Environment consuming Enterprise Services, it is of prime importance that the math around the calculations of Net Present Value, 
Cash-flows and ROI based on multiple scenarios and components be evaluated and put together to form the TCO calculator adopted by the business. Such a calculation would help provide a business meaning for the initiatives being undertaken. While
there are many tools available in the market today for calculating the TCO, not any tool brings together the value to be calculated in terms of business benefit accrued by the BPX. The Business benefit when equated on par with the TCO calculations would provide the Go, no-go decisions in terms of the perceived business value translated as costs and ROI. By going through such an exercise, Organizations can have a logical approach to the composites being built, the technologies being considered, the process being defined, the cost-savings being accrued, the tools being used and a business case for bringing all this together in terms of visual interpretation of this data converted into information that would provide a BPX with ample financial logic to proceed with a SOA initiative. Such an approach will also help sort out the build vrs. buy syndrome.

Mile 6: Aligning the Work & Control Centers

Aligning all the business process as a Visio (or any BPM tool) diagram can help a BPX apply the Zachman framework order to define the perceived value of such an application as a business benefit being converted. For example, if there is a composite being built to complete a Requisition to Order process, it would help translate the same not as being an application to automate the current inefficiencies, but rather in designing and defining a process to enable the cost savings per requisition to be lowered by a dollar, or by creating a process for creating POs in less than 6 minutes, thereby increasing user productivity. Once the process is mapped on the x-axis, the y-axis can be intersected to define the process step being executed by different roles that either exist, or will have to be created to make such a composite a logical one. The anatomy of such an application will be defined by the Enterprise Services Infrastructure, the work centers and the control 
centers will be defined by the roles that will exist in the organization. Once this is matched up and bundled up to a larger process set like, say - logistics, there would then be a super-set of roles and such centers for whom, the UIs can be defined to bring about an ESS/MSS like scenarios - rendered in a technology of choice for the performing cross-section of users.

Mile 7: Aligning Strategy with Tactics and Operations (The changing models of SIs)

On order to adopt a methodology and toolset  to support the effective adoption of practical Enterprise SOA. The need for such  framework being adopted by an organization in creating a meaningful SOA journey, the question now comes to the changing models of engagements for Large Offshore based System Integrators. SI revenue models will change and will have to adapt the Composition Environment on a stable SOA platform. SAP will have to co-exist with other platform vendors. Re-skilling in SI organizations will happen as core ERP skills will be in lesser demand. SAP Shops will slot Sis into 3 categories: a) BPO/KPO outfits as large organizations for low-end offshore work, 2) Niche companies for strategic definitions & c) Smaller organizations as Agile enterprises who embrace the BPP approach with SAP NetWeaver creating a pool of Enterprise Architects for shorter projects. Businesses will either look for high-end consulting, or low-end work outsourcing and will create a pool of Business Analysts to become more powerful IT evangelists. Outsourcing models will change. Businesses will leverage to create projects on a platform, will focus less on the product Implementations. Core ABAP skills will become non-critical. Java & OOABAP will be more in demand. This would help customers decide very clearly on what to outsource, what to keep within, redefine their IT core-competencies and be in a position to define the role of a BPX in the changing economy. Such an approach will have a lot of strategy work being collaboratively modeled by groups across the world (Strategy), small projects being led by Enterprise Architects (Tactics) and the off/near-shoring of non-core work in terms of operations. Decide what model will suit your organization.

The 8th Mile:

If the ESR gets populated with a bunch of core enterprise services and the quest will be on to define new services that will be more or less areas that SAP will not touch, the PIC process for such governance (design-time) will become critical and will have to be adopted universally for creating the services. Such services will lead the way for a hosted ESR that would enable niche process companies to work out a SaaS based, BPO outsourcing model and more of less lead the world to an "On-demand" solutions. If this were to happen, the SOA strategies being defined today will have to logically morph to a world of enterprise 2.0, mash-up corporations, SaaS and Applications as a service. Though the revenue models would have to be defined in terms of SOA governance, this would be the logical move for a lot of niche boutique shops to offer to SAP shops around the world.

Outro:

The above approach to a SOA roadmap will pave the way for large Business Networks being formed, circling back to the days of yore of the B2B boom with business exchanges with ridiculous revenue models. The same has a high probability of repetition, albeit in a more complicated manner with SOA, organizations having a larger perspective of the entire journey will find a higher chance of success with SOA. My next blog will feature ES Bundles and how that can be a double edge sword for SAP.