Welcome!

Microservices Expo Authors: Pat Romanski, Liz McMillan, Stackify Blog, Elizabeth White, Dalibor Siroky

Related Topics: Microservices Expo

Microservices Expo: Article

Considering the SOA Reference Model

Part I - Business Grounds

SOA RM: "...in SOA, services are the mechanism by which needs and capabilities are brought together"

Recently OASIS voted the SOA Reference Model (SOA RM) into a standard. In spite of its high level of abstraction, this model emphasizes the business orientation of SOA. This two-part article will elaborate on the business aspects of the standard. Part 1 discusses one of the possible business grounds for SOA and design-for-changes uses cases. Part 2 will describe several technical design pillars of SOA in light of the standard.

Business Agility
The SOA Reference Model (SOA RM) is the first standard that shifts SOA from a pure technical realm into the business world; you can see it right away from the SOA service description. You can wonder what "needs" and "capabilities" means; why an application in IT, which is considered to be an SOA service, becomes a mechanism; and, finally, where all the technical definitions of interfaces, clients, providers, QoS controls, etc., are. Don't worry, they're all in their places but now they have been repurposed toward business agility.

In particular, the SOA RM says: "the central focus of service-oriented architecture is the task or business function - getting something done." That is, in SOA, we're talking about a business function of the organization rather than about isolated business operations that implement the function today. The function is something the organization cannot exist without; the organization business model is the combination of such functions while the actual implementation of the function is the secondary category. Unfortunately, up 'til now, the majority of IT applications fit exactly into that category. Now SOA creates an opportunity for IT to become the business partner and perform as a function for its enterprise rather than just a support provider.

The SOA RM states that an SOA service operates in an "execution context," which is defined as a "set of technical and business elements that form a path between those with needs and those with capabilities." The standard expands the interpretation of "those with needs" and "those with capabilities"; "those" are not only IT applications and operations, they are the business elements as well, and, moreover, the business elements are first. If IT looks at its organization from the business perspective (versus operational/procedural ones), it can find that very few applications correspond directly to the core business tasks; other applications support a lot of just-this-moment operational requirements that were real years ago. If you add runtime and procedural application integration to this view, it becomes easier to see why IT has difficulties implementing and supporting frequent business changes required by the modern market.

Finally, when explaining how SOA differs from other models, the SOA RM outlines that it reflects business-motivating considerations that are expressed "within service descriptions and service interfaces." This is what SOA brings to the table the first time because a service description in the form of the service contract includes policies that "may also express business-oriented policies - such as hours of business, return policies, and so on." That is, some services in SOA elevate to the level of business entities. Now that it's more clear what "capabilities" are, we are saying that an SOA service can implement much more than the interface "API"; it's responsible for the functional and non-functional aspects, many of which might be invisible to the consumer though the service interfaces. Nonetheless, the invisible capabilities are just as important to the service consumer as the visible ones, because consumers now depend on the honest behavior of the service outside of the consumer's control. For example, your enterprise service engages a third-party service to publish your results on the Internet. Would you like to use that service if you find that it doesn't filter porn ads and they get or can get published with your data?

You are right, not every SOA service is that complex and there are a lot of simple and very useful services that IT can offer. However, the power of SOA is in the services that implement business services and, accordingly, get involved in the risks of real business life. In this article, I will go a step further and elaborate on how a business may be decomposed into elements useful for building SOA service applications, and what the IT managers and architects have to understand and deal with if they really want to modernize IT to be agile in business. That is, the article tries to position SOA as a business-centric application architecture driven by business (not by technology) and organized in a way that is oriented to support business changes, both today and tomorrow.

Business Model Decomposition
Since the SOA RM standard attempts to facilitate an enterprise technical architecture to mind real business functions, it would be worth finding out what they are. This way, one of the working assumptions we make is that every organization operates on the basis of its business model. A business model definition is still evolving; in this article, we'll use the one below:

A business model is "a conceptual tool that contains a set of elements and their relationships and allows expressing the business logic of a specific firm. It is a description of the value a company offers to one or several segments of customers and of the architecture of the firm and its network of partners for creating, marketing, and delivering this value and relationship capital, to generate profitable and sustainable revenue streams."

A business model also has instrumental and structural elements. For example, distribution channels and revenue models are instrumental elements while value configurations (the configuration of activities and resources) and core capabilities (the capabilities and competencies necessary to execute the company's business model) are structural elements. Talking about structural elements of the business model, we can recognize Business Services and Business Processes, the compositions of which constitute core capabilities. Both Business Service and Business Process have internal structures as illustrated in Figure 1 and described below.

The functional organizational decomposition of an enterprise model helps in recognizing its Business Services and Processes. Each Business Service is unique in the organization but may formally be described in the same way as other services. In particular:

  • The foundation of a Business Service is data: The data becomes business data when its business meaning is defined via business metadata. A Business Service specifies methods, activities and/or rules that might be applied to manipulate the business data. Business methods, activities, and rules may be grouped for cooperative execution in different scenarios. The latter have their own methods and rules for composing data processing activities; those compositions are usually called business operations and workflows. The execution of data manipulation methods, activities, and/or rules in business scenarios produces results. The results become business results when corresponding business metadata is defined. The Business Service frequently includes a delivery mechanism of the results to the business consumers although it is optional. (Other important elements of a Business Service such as documentation and audit rules and procedures are skipped here for the sake of simplicity.)

    A Business Service consists of at least one business unit of work, which encapsulates some business data and data processing activities. The entities of the data processing activities are different heterogeneous "things" representing additional data, applications, communication processes, human activities, information containers (e.g., a spreadsheet), and more. The business unit of work defines how a particular business task of the Business Service is implemented. The implementation is not crucial for the enterprise and is the subject of change based on solution availability (including technical ones) and market trends.

    Business Service changes, in its core, are infrequent and usually reflect industry and corporate policies or corporate restructuring. Instead, the Business Service may be extended or split into several new Business Services. What can and may happen to the Business Service is defined in the enterprise business model.

    A Business Process is defined in Wikipedia as:

    "a collection of related structural activities that produce something of value to the organization, its stakeholders or its customers. A business process can be part of a larger, encompassing process and can include other business processes that have to be included in its method. In that context, a business process can be viewed at various levels of granularity."

    In the Business Process, Business Services interact with each other according to special methods, activities, and/or rules. The interactions may be viewed as an exchange of the results (actual or logical) produced by the Business Services. That is, a Business Process consists of methods, activities, and rules for exchanging results between Business Services. Methods, activities and exchange result rules constitute the "things" the enterprise business usually changes to adapt to market needs. The richer the spectrum of changes available and the easier the changes are to do, define the market adaptability and business stability of the enterprise. SOA targets this exact area; however, without implementing Business Services (in addition to the technical services), SOA can't help in the Business Processes.

    At the entrance point into a Business Service, the foreign results become new data and the Business Service's stack starts again. Sometimes, metadata transformation is needed to convert foreign result interpretation into the local one. The transformation may be done either by adding additional metadata (i.e., accepting metadata provided with the foreign results) or by replacing some or all of the foreign metadata with internal metadata - business data interpretation.

    Thus, we can rephrase the goal of SOA:

  • The creation and maintenance of such application architecture that can effectively support corporate Business Services and Business Processes with the highest effectiveness and can quickly adapt to the changes in them.

    Thus, SOA may be viewed as a technical architecture built around an enterprise business model, not around isolated business procedures or just-this-moment operational needs. SOA is supposed to address current and upcoming business requirements, diversity, which is limited by a particular business model. If the business model is unclear in the organization, Services and Processes, SOA won't help but rather will confuse the company a lot.

    Design for Business Changes
    Forrester Research states, "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." SOA promises to make the changes faster and easier. Let's observe these changes.
    Looking from the enterprise perspective, we can find three types of possible change in the business that the technology has to support:

    • Changes in the business methodology of doing things (e.g., changes required by the Basel II regulations in financial credit management)
    • Changes in the set of tasks performed by a business service and/or in a business process (e.g., adaptation to the market trends)
    • Changes in the core of the business service, i.e., in the business model, dictated by the market dynamics (e.g., enterprise strategy change)
    SOA can help IT in two ways by:
    1. Offering services that can be easily combined in different compositions
    2. Hiding change implementations behind the service interfaces
    The first way is popular but it has significant pitfalls: to gain certain flexibility in the compositions, the services either have to be quite generic, which hits performance and risks losing control over details, or there should be a lot of fine-grained services available, which makes management and maintenance difficult and you can end up with a significant ballast of in-definite non-reusable services.

    The second way is the IT hope of SOA. However, those who hope are usually forgetting that the changes are not free due to the cost of retesting and revalidating all the dependencies (in the Service Contracts) and the actual support for multiple service versions - not all service consumers "are in need" of the changes at once.

    The following examples illustrate the third way of designing SOA services - the design for changes. This approach is based on an a priori knowledge of the business model and its potential modernization. Certainly, this way does not help in converting the service to a completely new one, but it covers the majority of other, smaller change-cases.

    Access Control System
    Assume we build an access control service based on roles. A user or subject in a role is permitted to operate on a resource - client's data - and perform the activities associated with or defined for the role. The role is equivalent to only one activity, e.g., "read," "write," or "edit."

    Due to business responsibilities, many users may or have to perform several activities but individual role assignment demands costly operational support. The business requires reducing the cost of the access control management and maintenance.

    Traditional Application-Centric Design
    IT decides to simplify management and maintenance by gathering users into groups and each group is assigned multiple roles. That is, all users in the group inherit all the roles from the group. The business objective of reducing costs is reached.

    In a while the market has changed and the client's data has received new internal dependencies. For some users, their duties have become conflicted with the new data dependencies and those users had to be restricted from acting in one of the roles, but they still have to perform in others.

    Since a group has been designed to provide inheritance of all the roles to all group members, the only possible way to restrict a user in the role is to create another group with a reduced set of roles and put those users into a new group. It's easy to imagine that if a group has a relatively small number of associated roles (three, for example), eventually we have to create seven groups to represent all possible combinations of the roles. Considering the realistic number of different clients and original groups in the firm, this becomes a maintenance nightmare. Plus, adding a new role to the initial group increases the number of group variations almost exponentially, and the operational cost rises correspondingly.

    SOA Design Style
    We have started by studding the business model and found that users may be grouped (to make management cheaper) based on their business responsibilities that follow certain corporate policies. This means the grouping should be changed if user activities are in conflict with the policies. Another potential reason for the access change is a reassignment of the business responsibilities to a user. With this business knowledge, the access control service has to be designed in such a way as to accommodate access changes even if current business requirements don't say anything about it (which, actually doesn't mean there isn't any problem).

    Instead of explicit role inheritance from the group to the users, each user becomes associated with a mask specified for the given group. The mask addresses all roles in the group and defines which concrete roles a particular user inherits from the group. As a default, all roles are inherited. If a user's access should be changed, the user's mask is modified and no new masks or groups are created. Plus, the modification may be based on corporate business policies. What we get is this: almost the same savings for the business but it works now and in the future.

    This described case fits into SOA very well because the change may be done behind the service interface transparently for the service consumers. However, if the service has not been designed for change from the beginning, it would be too risky adding the masks later (even behind the interface) because, in case of a mistake, it could create problems with resource access for many users and negatively affect corporate business service.


  • More Stories By Michael Poulin

    Michael Poulin works as an enterprise-level solution architect in the financial industry in the UK. He is a Sun Certified Architect for Java Technology, certified TOGAF Practitioner, and Licensed ZapThink SOA Architect. Michael specializes in distributed computing, SOA, and application security.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    @MicroservicesExpo Stories
    You know you need the cloud, but you’re hesitant to simply dump everything at Amazon since you know that not all workloads are suitable for cloud. You know that you want the kind of ease of use and scalability that you get with public cloud, but your applications are architected in a way that makes the public cloud a non-starter. You’re looking at private cloud solutions based on hyperconverged infrastructure, but you’re concerned with the limits inherent in those technologies.
    Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and co...
    It has never been a better time to be a developer! Thanks to cloud computing, deploying our applications is much easier than it used to be. How we deploy our apps continues to evolve thanks to cloud hosting, Platform-as-a-Service (PaaS), and now Function-as-a-Service. FaaS is the concept of serverless computing via serverless architectures. Software developers can leverage this to deploy an individual "function", action, or piece of business logic. They are expected to start within milliseconds...
    The cloud era has reached the stage where it is no longer a question of whether a company should migrate, but when. Enterprises have embraced the outsourcing of where their various applications are stored and who manages them, saving significant investment along the way. Plus, the cloud has become a defining competitive edge. Companies that fail to successfully adapt risk failure. The media, of course, continues to extol the virtues of the cloud, including how easy it is to get there. Migrating...
    As DevOps methodologies expand their reach across the enterprise, organizations face the daunting challenge of adapting related cloud strategies to ensure optimal alignment, from managing complexity to ensuring proper governance. How can culture, automation, legacy apps and even budget be reexamined to enable this ongoing shift within the modern software factory? In her Day 2 Keynote at @DevOpsSummit at 21st Cloud Expo, Aruna Ravichandran, VP, DevOps Solutions Marketing, CA Technologies, was jo...
    The nature of test environments is inherently temporary—you set up an environment, run through an automated test suite, and then tear down the environment. If you can reduce the cycle time for this process down to hours or minutes, then you may be able to cut your test environment budgets considerably. The impact of cloud adoption on test environments is a valuable advancement in both cost savings and agility. The on-demand model takes advantage of public cloud APIs requiring only payment for t...
    For DevOps teams, the concepts behind service-oriented architecture (SOA) are nothing new. A style of software design initially made popular in the 1990s, SOA was an alternative to a monolithic application; essentially a collection of coarse-grained components that communicated with each other. Communication would involve either simple data passing or two or more services coordinating some activity. SOA served as a valid approach to solving many architectural problems faced by businesses, as app...
    Some journey to cloud on a mission, others, a deadline. Change management is useful when migrating to public, private or hybrid cloud environments in either case. For most, stakeholder engagement peaks during the planning and post migration phases of a project. Legacy engagements are fairly direct: projects follow a linear progression of activities (the “waterfall” approach) – change managers and application coders work from the same functional and technical requirements. Enablement and develo...
    Gone are the days when application development was the daunting task of the highly skilled developers backed with strong IT skills, low code application development has democratized app development and empowered a new generation of citizen developers. There was a time when app development was in the domain of people with complex coding and technical skills. We called these people by various names like programmers, coders, techies, and they usually worked in a world oblivious of the everyday pri...
    While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
    From manual human effort the world is slowly paving its way to a new space where most process are getting replaced with tools and systems to improve efficiency and bring down operational costs. Automation is the next big thing and low code platforms are fueling it in a significant way. The Automation era is here. We are in the fast pace of replacing manual human efforts with machines and processes. In the world of Information Technology too, we are linking disparate systems, softwares and tool...
    DevOps is good for organizations. According to the soon to be released State of DevOps Report high-performing IT organizations are 2X more likely to exceed profitability, market share, and productivity goals. But how do they do it? How do they use DevOps to drive value and differentiate their companies? We recently sat down with Nicole Forsgren, CEO and Chief Scientist at DORA (DevOps Research and Assessment) and lead investigator for the State of DevOps Report, to discuss the role of measure...
    DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
    "As we've gone out into the public cloud we've seen that over time we may have lost a few things - we've lost control, we've given up cost to a certain extent, and then security, flexibility," explained Steve Conner, VP of Sales at Cloudistics,in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
    These days, APIs have become an integral part of the digital transformation journey for all enterprises. Every digital innovation story is connected to APIs . But have you ever pondered over to know what are the source of these APIs? Let me explain - APIs sources can be varied, internal or external, solving different purposes, but mostly categorized into the following two categories. Data lakes is a term used to represent disconnected but relevant data that are used by various business units wit...
    With continuous delivery (CD) almost always in the spotlight, continuous integration (CI) is often left out in the cold. Indeed, it's been in use for so long and so widely, we often take the model for granted. So what is CI and how can you make the most of it? This blog is intended to answer those questions. Before we step into examining CI, we need to look back. Software developers often work in small teams and modularity, and need to integrate their changes with the rest of the project code b...
    "I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    "Cloud4U builds software services that help people build DevOps platforms for cloud-based software and using our platform people can draw a picture of the system, network, software," explained Kihyeon Kim, CEO and Head of R&D at Cloud4U, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
    Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
    DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...