Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Microservices Expo

Microservices Expo: Article

SOA Web Services Journal: Save Our Architecture

Driving an SOA strategy top-down from the business

As I look upon the enterprise landscape today, I cannot help but wonder if the enterprises are going to be all right. Every couple of years, enterprises have to face the onslaught of their vendors who bring in newly coined phrases, acronyms, and newly minted software platforms, along with the promise of ROI. In the latest onslaught, enterprises are facing terms such as SOA, Web services, BPM, and BAM.

The new buzzword is AJAX, or Asynchronous JavaScript And XML. The speed at which the IT industry coins terms and makes it fashionable to use them gives the cool name creators in the fashion and entertainment industries a run for their money. System integrators and consultants capitalize on the confusion and introduce new solutions and services that range from architecture blueprinting to specific product implementations. Enterprises turn to industry analysts to understand who is the leading vendor of the current hype cycle and eventually cave in to the trend and buy another piece of technology to add to the existing collection. During the course of my career, I have been in all of the camps: vendor, consultant, and system integrator, which enables me to provide some unique and original thoughts on how to save the enterprise architecture.

Understanding Architecture
Architecture is the most misunderstood, yet most widely used word today in IT. This is a word that has been borrowed by IT. This word has its origins from Greek around the 1500s when the related word, architect, meant a "master builder." Today, architecture, related to usage in IT, is used very loosely to denote the art and discipline of creating software, computers, systems, databases, information, and enterprises themselves.

In order to make the right decision, one has to understand all of the options. To make the right decisions pertaining to SOA, one has to understand what SOA is as well as the available options. Though SOA is looked upon as a technical term, in order to make the right decision, SOA has to encompass business as well. Even before the term SOA was coined, I had consulted on numerous occasions with large enterprises on their "enterprise architecture." Companies have always been interested in ensuring that their investments in technology, applications, and infrastructure materialize into tangible gains either in productivity and efficiency of operations, or a direct impact to top-line and bottom-line growth. SOA cannot be viewed myopically as only a technology term that impacts the technology architecture of an enterprise.

SOA needs to be divided into four layers and addressed holistically:

  • Business architecture
  • Functional architecture
  • Technical architecture
  • Infrastructure architecture
Figure 1 shows that SOA is the most generic (commodity) at the bottom layer and is very specific (unique) to a particular way of doing business at the top layer. Even though two companies may be in the same line of business, industry vertical, and may even have the same business model, the business architecture is very specific and is dependent on the people, business culture, company history, relationships, business processes, and the business characteristics among other things that cannot be duplicated exactly by another business. On the other hand, the lowest layer is the most generic where infrastructure could consist of mainframes, networks, routers, servers, etc. Although the configuration and implementation of the infrastructure elements could be different, the important point is that as one traverses down the SOA layers, one goes from specific to more generic.

An enterprise has to first identify its business problems and prioritize them. Subsequently, it must figure out the business process characteristics of the business problem and its impact on the business architecture and model that within the context of the business architecture. This is easier said than done.

With this new way to look at architecture in general and SOA in particular, an enterprise now needs to catalog the artifacts that reside in its layers in order to embark upon a successful SOA strategy. The artifacts run the entire gamut, containing business processes, application, services, technical components, documents, policies, infrastructure components such as servers, and anything else that represents enterprise knowledge.

SOA and ROI: A Business Problem?
The SOA vendors sell everything from soup to nuts that fits into the SOA layers. The main point that is harped upon is that SOA will allow enterprises to create and make available "services" that can be put together to provide application functionality. Vendors such as IBM maintain that modular components should be easily defined and manipulated along with dynamic definition of application and operations (see the first entry in the References section). The attractiveness lies in the fact that these services can be located through a registry and that the services can be reused in multiple areas.

The risk of having loosely coupled services that orchestrate business processes is that there is really no control over what is transpiring during process orchestration. BPM vendors realized this and provided products to design, visualize, and orchestrate business processes. However, that was not enough. The IT infrastructure and applications that supported the process orchestration were now loosely coupled and were represented as services. As such, vendors stepped in to manage applications and services and monitor business activities. The vendors that offered products in this area originally were specialized, from managing only infrastructure, servers, network etc. to managing only Web services or applications.

The problem with existing SOA solutions is that there is also no attempt to model the business problem. There is an attempt to model the processes (BPEL, BPMN). There is an attempt to model the software system (UML). Business Process Execution Language (BPEL) is a way to represent orchestration between two parties. Several vendors jointly submitted this standard to Oasis and the standard is at version 2.0 currently. Business Processing Modeling Notation (BPMN) is a way to represent workflow graphically. As such, BPMN complements BPEL. Neither BPEL nor BPMN provides a way to understand the business issues that may arise inherently from business process orchestration. They also do not provide a way to correlate disparate business-related events that occur as a consequence of process orchestration. There is no attempt to model the specific set of business issues. That is the gap in the current approach to SOA. It is currently being addressed from a purely technological angle with the technology decisions driving the business decisions. This is contrary to what one observes when analyzing SOA as a layered architecture. It is clear that the business architecture is the most specialized and must drive the rest of the architectural decisions. Forget the business-to-IT alignment in the enterprise: there is no business process-to-software systems alignment in the SOA model. Vendors such as Red Rabbit Software have bridged that gap with a business domain modeling studio.

A research field called Complex Event Processing (CEP) has been around for many years now Advances have been made in a related area called Business Event Processing (BEP). Alert readers will immediately notice the introduction of two new terms in keeping with the rapid pace of name generation in IT. BEP is related to CEP in that there is an attempt to relate events in time and space (causality) as they transpire during business process orchestration. There have been attempts to apply CEP to various problem areas, but the application almost always tries to work its way up from the technology layer and tries to bridge the occurrence of technical events to possible business causes. CEP is more applicable, as it stands today, to scientific and technical problems whereas Business Event Processing targets business domains, business pain points, and business models, as well as how to take a top-down approach from the business architecture and make an SOA strategy successful.

By utilizing BEP, an enterprise can first model a set of business events that relates to its business issues. These issues are encountered specifically within a business domain. For example, a consumer packaged goods company may have issues with its inventory levels and safety stock whereas an insurance company may have problems with the cycle time taken to process an insurance policy application. Once a business domain model has been created, it is mapped to the actual business functionality that supports the business processes. By utilizing the BEP platforms, it is now easier to enable only the impacted applications to conform to an SOA strategy while, at the same time, ensuring that the specific business issues that plague a particular domain are better understood. Visibility into the business problems will now be possible, all the way from the business architecture through the entire SOA stack.

In order to realize ROI from investment in SOA, an enterprise needs to clearly articulate its business issues and what is quantifiable and measurable with regard to the issues. Any SOA technology adoption should also include a platform that would help model business issues and then allow an enterprise to track the solution to the modeled issues. Also, there is no single solution to the SOA technology. SOA needs application servers, Enterprise Service Bus, Business Processing Modeling, and Business Event Processing in the technical architecture layer, and these technology components come from different vendors.

The challenge also is whether the newer technologies can work on top of existing technologies. An SOA strategy will take a few years to implement and the new technologies will have to work with the existing (and in most cases legacy and proprietary) technologies to ensure that it is "business as usual" in the enterprise while the architecture is undergoing transformation. Enterprises cannot afford to run a parallel IT department while waiting to convert their existing applications to SOA and then flip a switch to the new architecture. The real problem is that most of the existing SOA approaches take an "all or nothing" approach with respect to enterprises.

More Stories By , Venkat

Venkat has over 13 years of experience in distributed computing, technology strategy, and enterprise architectures. Venkat is the chief technology officer at Red Rabbit Software where he leads the Business and Technology Strategy, the direction of the Red Rabbit Software technology platform, and Research & Development. He has completed PhD courses in Interdisciplinary Studies involving Computers and Aerospace Engineering and has a Bachelor of Technology degree from The Indian Institute of Technology, Madras, India.

Comments (5)

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.

Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
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...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...