Welcome!

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

Related Topics: Microservices Expo

Microservices Expo: Article

SOA Governance Best Practices – Architectural, Organizational, and SDLC Implications

Taking the management of services to the next level

The fact that you're reading this article means that you are probably planning a service-oriented architecture (SOA) initiative and recognize that some level of governance is required in order to be successful. If you are like most people in this position, you are also somewhat confused as to the meaning of SOA governance. Governance is the current buzzword, and combining governance with SOA creates a phrase that every independent software vendor (ISV) wants a piece of. How do you sort out what is marketing hype from what is truly valuable and relevant to your organization's SOA efforts?

Governance Scope Within an IT Organization
Much of the hype around SOA governance has been focused on operational governance. Defining, tracking, and managing factors like service-level agreements (e.g., average response time, peak response time, average throughput, peak throughput) and authorization policies (e.g., users from organization A are allowed to invoke this service while users from organization B aren't) are clearly important once the pieces of an SOA get up and running within an organization's IT infrastructure.

However, while operational governance and management is necessary for a successful SOA initiative, it is not sufficient. For an organization to effectively define and implement an SOA (and not simply implement a series of point-to-point services masquerading as an SOA, but in fact creating another layer of technology spaghetti), it must extend SOA governance back to the development and architectural perspectives. To be successful with SOA, you must find a way to bind these perspectives together as seamlessly as possible to enable effective information flow in both directions: from architecture to development to operations, and vice versa. Let's investigate each of these governance perspectives in turn.

Architectural Governance
Architectural governance at the enterprise architecture (EA) level involves three key elements: 1) making core decisions about business or technological functionality within the enterprise, 2) sufficiently documenting those decisions so that downstream consumers (the teams responsible for developing and deploying services and applications) can quickly understand and make effective use of those decisions, and 3) reviewing the project-specific application of those decisions. In order for an EA team to execute these tasks, it must have at its disposal an effective way to disseminate the knowledge assets it produces, to track and understand which knowledge assets are being applied to specific projects, and to document the review of those project-specific decisions.

Design-Time (Development) Governance
In many ways, Software Development Life Cycle (SDLC) governance within an SOA initiative is a reflection of decisions made at the EA level. Decisions about the scope and granularity of business services to be implemented and the technical approach to be used in implementing those services must be applied to specific service production or consumption (i.e., application development) projects. However, SDLC governance extends beyond appropriate application of EA guidance to the actual analysis, design, implementation, and testing of the resulting services and/or applications required by the IT project at hand. With respect to service production, SDLC governance involves the progressive "hardening" of the service as it progresses through its requirements definition, design, implementation/unit test, and integration/system test phases to eventual deployment in the operational environment. When applied to service consumption, governance may involve both internal project-specific reviews (e.g., have the appropriate services been selected, have requirements for new services been identified) and external reviews from the perspective of service providers (e.g., does the use of this service within this application conform to enterprise-specific or government-mandated privacy rules, does the service implementation contain open source components and if so, are the components used in a manner such that enterprise-specific intellectual property is not compromised).

Operational Governance/Management
Operational governance/management within an SOA involves applying appropriate business and technical policies (e.g., which groups and users are allowed to invoke a particular service, what are the minimum throughput and response time expectations required of a service) to deployed services. Business policies are often implemented within an SOA by an Enterprise Service Bus or SOA Fabric integrated with the enterprise's authentication and authorization infrastructure, while technical policies are typically monitored by a services management platform. The cumulative set of governed technical policies is often referred to as a service-level agreement (SLA). Examples of SLA-level technical governance elements within an SOA are:

  • Average throughput
  • Peak throughput
  • Type and description of committed SLA
  • Availability
  • Consuming service clients
  • Hardware and software configuration
  • Fault history
  • Alert thresholds
Political/Organizational Aspects of SOA Governance
How do we map these governance disciplines into an organization's structure and roles? Because of the loosely coupled nature of SOA, SOA governance is a new discipline that has implications for existing corporate and IT institutions as well as for new organizational structures and processes (and the politics associated with those structures and processes). Proper focus on what governance is, how it can be achieved, and its implementation can help make governance a valuable and necessary function to support your SOA migration.

SOA governance has an impact on current IT governance processes. Some of these processes include the budgeting and project approval process, portfolio management activities, and ongoing oversight of projects to assure budgetary compliance. Applying governance to SOA activities is critical because there may have to be changes to the normal IT governance processes for budgeting and portfolio management.

Think about the budgeting process of your organization. That budgeting process has a tremendous impact on the behavior of various organizations and their IT representatives. If there is no budgetary control of projects to influence them to adopt SOA and reusable services as their fundamental design concepts, then projects will go their own way as driven by the requirements of that particular business unit or project. The same goes for the portfolio management process. If there is no mechanism to surface SOA and reuse opportunities for all projects and then apply budgetary pressure to converge them toward an SOA, then they will similarly go their own way. SOA governance, budgeting, and portfolio management are ways to influence behavior of business units, as well as the IT and business personnel within them, to more aggressively support SOA and reuse.

Enterprise architecture processes may undergo similar changes given the advent of an SOA initiative in an organization. Often the architecture process and organization will have to be restructured to accommodate the requirements of an SOA initiative because the skills, roles, and functions of an EA team are not completely appropriate for an SOA initiative. Think about the process of architecture as two tiers of activities: one tier is the architecture strategy and goals, followed by the definition of the elements, standards, and organization of architecture to accomplish those goals. The second tier is the application of architecture to funded projects, the acquisition or implementation of various technologies and standards, and the enforcement of compliance to the enterprise architecture goals (see Figure 1).

These are two related yet distinct processes, and often they are not as interdependent as CIOs would like. Think about the cases where there is a chief architect or central architecture group at corporate headquarters, and then also present are the solution architects assigned to projects. They actually build systems and implement technologies and standards. Who has the most direct bearing on the architecture that ultimately is implemented in a given organization? Naturally it is the person assigned to the budgeted project that was sponsored by a specific business unit that ultimately funded the project. The behavior associated with enterprise architecture is similarly related to the organization and processes used to achieve the goals of SOA, architecture compliance, portfolio management, and budgetary compliance.

More Stories By Brent Carlson

Brent Carlson is vice president of technology and cofounder of LogicLibrary, a provider of software development asset (SDA) management tools. He is the coauthor of two books: San Francisco Design Patterns: Blueprints for Business Software (with James Carey and Tim Graser) and Framework Process Patterns: Lessons Learned Developing Application Frameworks (with James Carey). He also holds 16 software patents, with eight more currently under evaluation.

More Stories By Eric Marks

Eric Marks is founder, president, and CEO of AgilePath Corporation, a service-oriented architecture (SOA) and Web services consulting firm based in Newburyport, MA. Marks is a software and technology veteran with 18 years of experience with firms including PricewaterhouseCoopers, Cambridge Technology Partners, Novell, Electronic Data Systems, StreamServe, Ontos, and Square D/Schneider Electric.

Comments (2)

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...