Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Talking about SOA and Business Architecture, you know what I mean, don't you?

user-pic
Vote 0 Votes

... or you just think you know? Unfortunately, we use the same words that mean different things to each of us. Recently, I read very promising article written by Dr. Nitin Nayak and colleagues from IBM called "Core business architecture for a service-oriented enterprise" and got a great example of our disconnection in semantics.

In the article, I could not find any definition or specific service-oriented enterprise other than a note "The current trend toward a service-oriented enterprise necessitates a formal characterization of business architecture that reflects service-oriented business thinking" in the middle of the fourth page from the beginning. What does mean 'thinking' in this case, how this reflects in business objectives, behaviour, and structure? Answers to all these questions are omitted. At a glance, any enterprise tends to serve market needs to some degree. Thus, why we outline the very service-oriented enterprise?

This is the fundamental point because without clear understanding (or agreement on understanding) what a service-oriented enterprise is it is useless to discuss its Business Architecture isn't it? In my book 'Ladder to SOE' (SOE stands for service-oriented enterprise) I analysed definitions from several authors and concluded:

"A Service-Oriented Enterprise is an enterprise that organizes and implements its business model based on service-oriented principles, from the top of the enterprise business down to the informational technology products. ... (SOE) is - a business organization whose Business and Technology converge based on the enterprise business model and service-oriented principles to achieve business goals and objectives in the most efficient way in dynamically changing external environment"

The definition of the business organisation anticipates the type of Business Architecture is needed for it. As we know. Business Architecture a fundamental structure of organisation's business capabilities, their inter-relationships and common principles shared in these relationships. In this light, the article's statement "The business architecture of a service-oriented enterprise can be adequately represented through five main architectural domains: business value, structure, behavior, policy, and performance" is, at least, unjustifiable. Why these five domains are architectural domains and why are they the main domains? I am afraid that we face the same out/in versus in/out view problem where out/in view sees what it wants to see irrespective the reality.

The authors of the article help us to 'dig' a bit deeper and find that:
• "The business value model [of the Business Architecture] describes how an enterprise participates within a network of enterprises, how it produces value, and what constitutes the basis for strategic decisions regarding its offering portfolio and partner relationships." Very well and we can find what business values particular Business Architecture targets, how an external market and 'a network of enterprises' influence the enterprise Business Architecture but 'how it produces value' is a non-architectural substance; 'how' belongs to the architecture implementation performed by the corporate management.
• "A business structure model describes how the enterprise organizes its work in the form of non-overlapping business functions." If I may rephrase this statement, I would talk about business functional structure model. In my opinion, this is the one and only one viewpoint that adequately reflects the essence of enterprise Business Architecture.
• "A business behavior model describes how an enterprise defines its internal business operations and the behavior of business partners exposed within its business ecosystem. " This is, probably, consistent behaviour model, but I do not see what the out/in view on Business Architecture contains because in/out view is empty. Business operations are the fundamental part of any enterprise, the part that realises Business Architecture. The same Business Architecture may be implemented via my different operational models. This means that Business Architecture may be aware of an influence the business operational model but this model is out of the scope of the Architecture. Looking at the business architecture from an independently created operational model with give no certain information about the business architecture.
• "In this context, business services represent the externalized view of the operations of a service-oriented enterprise." This is it. The statement saying that "business services represent the externalized view of the operations" may be applicable to any enterprise and this is how Business uses the term 'business service' in our days. Moreover, this statement applies predominantly to the badly organised enterprises because an externalised view, i.e. the consumer's view, has to outline business functionality important to the consumer rather than the internal operational 'kitchen' of the enterprise. Successful enterprises expose only services and results of internal processes and procedures; customers who are enforced to deal with internal enterprise processes run away from such enterprises at the first possible moment.
• "The notion of business policy is critical to specifying directions and guidelines for all aspects of the business architecture. " Yes, it is, indeed. However, since when policies, i.e. governance, became a part of Business Architecture? Governance situates above Business Architecture and governs it. Business Architects realise governing policies and control the rest of the enterprise how it preserves them. In the given statement, the authors mixed the subject of Business Architecture with the Discipline/role & duties of Business Architects. Using out/in policy viewpoint, we can find what policies the business architecture implements, but we will not be able to learn what the business architecture is it because the same policies may be implemented by quite different architectures.
• A "business performance model specifies the elements needed for evaluating the performance of the enterprise, according to key performance indicators (KPIs), as well as specific business operations." The article's section related to the business performance model accurately describes KPI with a supply-chain example. It also outlines the "the concept of commitments from management of the service provider organization to its clients", which is a common place for any service-oriented or not service-oriented enterprise.

My overarch impression is that the article is very good in describing, explaining and illustrating regular business service to external customers. This has no service-oriented specifics whatsoever, this service may be provided by any enterprise and related business architecture may be anything you want.

Here we are dealing with quite frequent case where an illustrative construction has a very weak or irrelevant foundation. The title of the article appears to mislead after all because the content of the article has missed the major, fundamental 'brick' - the concept of service orientation as the constructing means of the enterprise business and related Business Architecture. I think that organisations like BUSINESS ARCHITECTURE INSTITUTE.ORG and Standards Bodies such as OASIS, OMG, The Open Group have to put more efforts onto standardisation of service related semantics used as in both Business as in Technology.

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