Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

The Enemy of Service Orientation: SOA Alert, Part 1

user-pic
Vote 0 Votes

Observing current development practice in the sphere of Service Orientation, I have found (not without a surprise) three almost unrelated domains that have potentials of or already slow down an adoption of Service Orientation between Business and IT. These domains are:


1) Cloud Computing
2) Systems Operational Support
3) Outsourcing companies.

Are you surprised as well? Then let's analyse the cases together.

As we know, SOA is a global paradigm covering both Business and Technology, which is confirmed by the OASIS Reference Architecture Foundation for SOA. This means that a SOA Service is a cohesive composition of business manual and automated operations dedicated to particular business function. The role of Technology in this composition varies but usually it is very important if not crucial. The expression of one of the analysts - "The reality of the digital age is that your business is embodied in your technology - you don't have a business until you have it implemented in your technology base, and your business can change only as fast as your technology can" - becomes true for more and more industries.

The major consequence of this understanding of SOA is a need for a close relationship and collaboration between Business and Technology. For the business to be successful nowadays its technology arm has to breathe the same air with business. Service Orientation should become not only a model for the business products but also an organisational principle of the corporate business.

In this light, it is evident that SOA does not appreciate a tendency of departing Information Technology into the Clouds, which is frequently promoted in the Cloud Computing. Public Cloud Computing certainly has its niche (primarily in the companies of micro and small sizes that need but cannot afford IT Departments). When the companies grow, the need in strong ties between Business and Technology becomes inevitable. Natural Service Orientation in Business will necessitate coupling with Technology or, at least, a full business transparency of the technical parts of the business. This means that business investments will turn Cloud Computing into something much closer to the corporate business than the public Cloud Computing anticipates. For the mean time, the CIOs do not move forward being at the cross-road - whether to go where the monies are, i.e. with Business SOA, or to go where immediate capabilities are higher, i.e. with public Cloud Computing, which still has not proofed if it is good in the adopting business changes.

A more dangerous opponent to SOA is Systems Operational Support. Several years ago the technology leaders understood that SW products (and respectively business consumers of these products) suffer a great deal from the problems attributed to the inadequate belated testing. The SW development methodology was changed requiring testing functions to participate in the development cycle at the earliest stages of the business requirements study. Tested were able and had to study the architectural and design solutions to validate related implementations versus business requirements. The Systems Operational Support personnel have not been that lucky as testers and staid far behind the development 'a vanguard'.

The fundamental thing about SOA is its distributed nature. SOA implementation must scale from a couple of Virtual Machines to a Grids. Each SOA Service is an application on its own, with its own live-cycle and deployment policy. When we approach SOA design from the business practicality perspective, you find that the number of business services is not that large in an enterprise or in the a corporate division. This number barely reaches the level of a hundred, may be a few hundreds. However, if your Systems Operational Support is unaware of SOA distribution, you can expect a fatal confusion among the people when you drop a hundred new applications (instead of one) on the heads of the Support guys.

Let me refer to the recent discussion between Alexander Johannesen and Steve Jones (the author of the first book about OASIS SOA RM standard) - Alexander: "Seriously, even in the mires of dogmatic enterprise there is a huge push for better handling loads and volume, and the answer to that isn't faster CPU's, but distribution", Steve: "Yup I'm sure about that because 99% of people in IT can't handle distributed systems problems." Here is what usually happens in Systems Operational Support: when a sophisticated or complex in logic SW product is released for support, the chances for this product to survive are minimal because it is too difficult for the Support people. When Business SOA starts in the organisation, the Systems Operational Support gets a double impact - from the business people and from the technical 'complexity'. Who would like this?

Actually, SOA is not complex at all, it does not require or use any technology that has not been known and used before but the volume of the independently working Services that also share the same information resources simply exceeds the Systems Operational Support human and technical resources. IT development planning considers the capabilities of the Systems Operational Support with the least priority, and the Support pays back with the same currency. Business SOA will be successful in Technology only if you invest not only into development but into the production support as well. If you do this investment, the Systems Operational Support will be Your supporter; otherwise volume-related stress will overwhelm people and they will start 'simplify' or trick your SOA products, just to survive. A few failures in production caused by simplified deployment and ignorance to the proactive monitoring of dozens simultaneously interacting services hurts the reputation of the product and users start looking for alternatives. That is, a good product in over-simplifies environment heads to the end.

However, this 'enemy' may be converted into an ally if you properly manage it. This management includes up-front training and investment into the right tools. Yes, the monitoring tools for distributed SOA solutions are not cheap but the task these SOA solutions realise are the business tasks. Business has never benefited from cutting its ability to know how it works and what prevents it from working better. So, do not be afraid when asking for proper investments into the Systems Operational Support when you deal with SOA solutions (of course, if they are real Business SOA solutions).

(continued)

Book Announce.JPG

4 Comments

| Leave a comment

Michael, nice posting. I especially liked the discussion about the Ops support personnel.

Thanks, Tarak. I hope, that the Part 2 about outsourcing would get your appreciation as well...

Just a slight comment (as I agree and like what you've written) that when it comes down to it, a load-balancing act - something terribly common and that any IT person actually understands - is a form of distribution. (And Steve's reply is put up as "John" which I think is wrong :) It's simply not true that distributed systems on the back-end are that hard nor mysterious. We all have a load-balancer, a switch, a multi-core CPU that we interact with, sometime configure and sometimes even develop for.

As to the fact that SOA doesn't change hardware is spot on; it's mostly a way of thinking, only sometimes a way of doing.

Alexander, thanks a lot for the clarification (I will correct my mistake about ‘John’ with apologies to Steve). Yes, we certainly use load balancing and “is a form of distribution�. What Steve said sounds to me as an emotional explanation of the fact purely distributed EJB 2.x components and the entire concept of Enterprise components has been killed in EJB 3.0 for the sake of OO programming (POJO). That is, majority of people resisted accepting distributed computing mindset in their daily job...

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Categories

Tag Cloud

'Navigating the SOA Standards Landscape, 1471, abstraction, ACM, active service, Adaptive, ADM, adopt changes, aggregate service, AIA, Amazon, analysis, API, application, Application Integration Architecture, architect, Architect, architectural mission, architecture, Architecture, architercture, AWS failure, Azure, B-SOA, BAWG, BEI, Best Practice, bottom-up, BPEL, BPM, brokerage, Brokering, brokering, bus, Busienss, busienss case, business, Business, Business Architect, Business Architecture, business architecture, Business architecture, Business Architecture Working Group, business concerns, business data, Business Ecology, business efficiency, business model, business operational model, business organisation, Business Platform Division, business process, Business Process Designer, Business Requirements, business risk, business service, Business service, Business SOA, business value, business view, business-centric, Business-IT problem, BuTechCon, Canonical Schema, capability, Case, CBDI, CBM, Centralization, choreography, CIO, Cloud, cloud, Cloud Computing, Cloud of Clouds, COBA, Collaboration, collaboration, collaboreation, commodity, component, Composite Application, composition, concept, Conciliator, consumer, contract, COSMIC, cost, cost estimate, cost of ounership, cost of ownership, coupling, crisis, CRUD, culture, Cutter Consortium, data ownership, data service, data store, DDD, decision logic, decomposition, definition, demand, design, Design Pattern, development, discipline, distributed orchestration, Domain, domain, Domain Aggregate, Domain Events, Domain Service-Oriented Modelling, DOSOM, DOSOSM, driver, Dynamic Process Edition, EA, EC2, ecosystem, EDA, efficiency, end-to-end, enemy, enterprise, Enterprise, Enterprise Architect, Enterprise Architectural Framework, Enterprise Architecture, enterprise architecture, ERP, ESB, event, Event, execution context, Execution Context, expertise, explicit, failure, fake, feature, Flexibilit, flexibility, FPA, FSM, Full Functional Points, Functional Points, functionality, functionality model, future, Gartner, goal, Governance, governance, granularity, harmonization, Healthcare, how to, IBM, identiy credential, IEEE, IEEE 1471, IFPUG, implementation, implicit, intangible, intangible value, Integration-Oriented Architecture, intent, interface, interface orientation, Inventory, investment, IOA, IT, IT Architect, IT Operation Support, IT organisation, IT without the IT Department, ITIL, Java, Ladder to SOE, leasable Cloud, lease, Loose coupling, Lost in Translation, Malik, management, Management, Manifesto, market, MDA, Michrosoft, Microsoft, Mike Rosen, model, Model-Driven Approach, modelling, Navigating the SOA Standards Landscape Around Architecture, navigation, OASIS, OASIS SOA RA, OASIS SOA RAF, OASIS SOA Reference Architecture Foundation, OASIS SOA RM, ODBC, OMG, ONA, Ontology, OO, Open Group, Oracle, orchestration, organizational change, outsourcing, ownership, participant, pattern, patterns, people, planning, policy, principle, principle of separation of concerns, principles, Principles, priority, Private, Private Cloud, process, Process, process-oriented, process-orineted, process-service, project, Provisioning, Pub/Sub, Public, Public Cloud, Public Cloud Busienss Requirements, QCon, RA, RAF, re-composition, Real World Effect, Real World SOA, redundancy, Referemce Architecture, Reference Architecture, Reference Architecture Foundation for SOA, Reference Model, Registry, rent, rentable Cloud, Repository, reuse, RIA, risk, RM, ROI, RPC, rules engine, RWE, SCA, scalability, Schema, security, semantics, Service, service, Service Autonomy, Service Composability, service contract, Service Contract, service description, Service Description, Service Discoverability, Service Execution Context, service orientation, Service Orientation, Service Oriented Enterprise, Service Relative Autonomy, Service Reusability, service semantic, Service Separation of Concerns, Service State Management, Service Statelessness, service-oriented, service-oriented eco-system, Service-Oriented Enterprise, service-oriented enterprise, service-oriented environment, ServiceContract, seven properties that differentiate emergent architecture from the traditional approach to EA, shared interface, shared library, simple, situational, sizing, SLA, SO, SO environment, SO Principles, SOA, SOA Manifesto, SOA standard, SOA-RAF, SoaML, SOBA, social, social networking, SOE, SOEA, software, solution SOA, SOMA, Spring, stakeholder, standard, Standard, study, subject, Summit, supply, supply chain, support, system, T-SOA, tangible, tangible value, Technical, Technical Architect, Technical Architects, Technical Architecture, technical capabilities, Technical SOA, technology, Technology, tendency, The Open Group, TOGAF, TOGAF 9.0, top-down, transparency, UI, UI Mediator, unstructured, use, Value Chain, Value Network, Value Networks, view, view model, viewpoint, vision, VNA, VPEC-T, WCF/WF, Web, Web 2.0, Web Service, Web Services, WebSphere, WS-CDL, WSDL, ZapFlash, ZapThink,

Monthly Archives

Blogs

ADVERTISEMENT