Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

What BEI needs from Cloud Computing?

user-pic
Vote 0 Votes

First of all, BEI stands for new OMG movement called Business Ecology™ Initiative. It is described as "focused on erasing the artificial lines between business and Information Technology (IT) so that IT becomes a ubiquitous, integral and vital asset to the company and leads decision-making, structural change and enterprise-wide quality initiatives, drives efficiency and revenue, and provides measurable, clear return on investment."

In the front quotes of 'Ladder to SOE', I've written: "Service orientation is Business means convergence with Technology to adapt to market changes. Service orientation is Business means departure from Business into Cloud Computing." Which part of this statement do you disagree?

In spite of fanfares plaid to Cloud Computing, there are relatively many questions remain in the area of usefulness and usability of Cloud Computing to Business. Even if we look at the IT and Business dynamics described in the OMG's Business Ecology™ Initiative white paper, it is not that clear how business oriented BPM can stay under the business control being partially or fully outsourced into Cloud Computing.

At certain level of abstraction, we can recognise, at least, three categories of Cloud Computing:

1) Development (Platform-as-a-Service) - consumer of Cloud Computing can develop and deploy new applications in the Cloud
2) Hosting (Infrastructure-as-a-Service) - consumer of Cloud Computing uses hardware infrastructure of the Cloud provider for deploying complete applications
3) Functional Outsourcing (Function-as-a-Service) - consumer of Cloud Computing fully outsources business applications to the Cloud or lease available business applications from the Cloud

Since Functional Outsourcing category lays outside of the controlled business realm of an organisation, I will concentrate on the Development and Hosting categories.

Development Cloud Computing is not mush different from the internal computational IT model because, in essence, it is only about leasing/renting computational power. The benefit of this category is relatively cheap and well maintained computational power that must be only available and accessible on demand. Since the business organisation still manages development and deployment of its applications in the Cloud, the latter has to provide the consumer with certain types of information about application operation at the run-time.

A scope of business concerns for the Development Cloud Computing is known and includes (in no particular order):

1. Security in its entire means (access to functions and data, confidentiality, integrity, etc.)
2. Political and legal issues based on transition information into unpredicted locals with different local laws and regulations
3. Compliance and regulations issues are similar to the political and legal issues but have additional aspect consumer compliance: different consumers adopt regulations in different time that Cloud Computing providers cannot control and manage
4. Business Service Continuity and Disaster recovery of the Cloud Computing environment that is not influenced by the consumer and, thus, constitutes high level risk in this area
5. "Long-term viability--What happens to data if the company goes out of business, and is data returned and in what format?"
6. Reliability and robustness of the Cloud Computing environment

These concerns appear stronger if one looks at the picture from the Business/IT agility point of view. For example, if IT massively moves its applications onto the Cloud Computing platform, how much trust may be between Business and such IT considering that IT cannot guarantee Business Service Continuity any more? It is a big question to the Business whether the short-term efficiency of IT (a drop of its cost) based on Cloud Computing outweighs the unmitigated risk of business continuity and, finally, the risk of business existence. It is obvious that Business Ecology™ cannot accept Development Cloud Computing until mentioned concerns are addressed and resolved.

The situation gets even worth for the Hosting Cloud Computing because such hosting assumes contractual relationship between the business and its instrument support. The Cloud providers cannot predict the direction of new business needs until they are articulated in the contact. That is, Hosting Cloud Computing strengthens the "lines between business and Information Technology (IT)", which BEI aims to erase. For the companies to become more efficient within market dynamics, Business needs Technology to react to the business requirements, i.e. business changes, almost instantly. This is due to the fact that a modification in Technology takes 3 times longer than in Business, and Business cannot and will not wait even longer for the negotiations with the host. If IT introduces new administrative and operational threshold between formulated business needs and implementation capabilities in the Cloud - 'a contractor of my IT is not my IT' - it may be not healthy for the Business Ecology™.

Aforementioned threshold causes Technology to move off Business. The consequences of this step may include:

a) degradation of business flexibility - every, even small, change in the technical instruments (including Web Sites and calculation engines) requires more complex operational procedures of interaction with The Cloud providers
b) ruining the business innovations that require technical facilitation - IT initiatives become boxed by existing contracts with the Cloud providers. I doubt that in the described case Business would call IT to participate in new initiatives and to delegate IT solutions of certain business problems; internal IT becomes a controller of external Cloud Computing.

One of the crucial aspects of Business Ecology™ is about creating such informational space where technologists and business specialists could exchange even 'crazy', at a glance, ideas to facilitate innovations or optimization of existing solutions. However, existing separation between Business and IT will be aggravated by the Technology distancing into decoupled state of Cloud Computing. Forrester Research said: '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'. I think that Cloud Computing still has to prove its ability to support 'build for changes' type of technical architecture.

So, the BEI needs Cloud Computing to be fully manageable by the corporate business and ready for big changes and enhancements, at any moment, with minimal cost and time to market. If Cloud providers can do this or, at least, plan to provide for such quality requirements, the BEI will go for it; otherwise, Cloud Computing risks making things cheaper but worth. We need to think about before moving forward.


Reference Lable.JPG

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