05
Sat, Oct
2 New Articles

SOA Governance: Better Now Than Never

General
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

An ungoverned SOA project can lead to unintended consequences, reversing the cycle and causing SOA to add cost and disrupt processes.

 

The year was 2004. John was a CTO for an IBM ISV that piloted a supply chain application. The company used a SOAP engine inside the IBM Websphere Application Server (WAS) with Enterprise JavaBeans for the front-end and connections to an i5/OS RPG application using WSDL.

 

The idea behind this was point-to-point integration, the kind where Web services and consuming applications are designed at the same time. These were easy to create. But as the business changed and more clients requested Statements of Work (SOWs), those point-to-point Web services became obsolete. Worse, since these Web services were easy to build, developers had a blast creating services. The quality of the service was in various states (and some not well thought of).

 

By 2007, the company had created many Web services, with no thought process. No one was sure which applications were using the Web services. With numerous SOWs created, no one knew the history and ownership.

 

SOA is great, but unless it's managed, it's just another IT process that can be chaotic. John contacted Gartner Group, and they recommended to put into place an SOA Center of Excellence (COE) to act as a focal point, establish reference architecture, review newly created Web services, communicate and enforce the standards, and encourage a higher degree of service reuse. Implementations are typically coordinated with clients, and unless strict governance exists, different groups or individual developers will make different decisions, increase diversity, and inhibit reuse.

 

Things had been uncontrolled for some time. John realized that the current mode of operation, with numerous out-of-hand Web services, could not be continually sustained and could not support the numerous SOW requests.

 

John finally understood the difference between Web services and SOA. It is easy to create Web services, but it takes discipline to deliver meaningful and serious value from them. John had used a spreadsheet to track Web services and all their dependencies, but this became insufficient. Many clients were asking for more details about the various services. John had a hard time keeping the spreadsheet up to date; it was error-prone. A registry and repository for SOA was exactly what he needed. How could John encourage reuse if no one could find information about what services might be available for reuse?

 

Tim Everett, the CFO of National Parts Distributor (NPD), approached John about modifying NPD's Web service-enabled warehouse management system (WMS). NPD required that various inventory inquiry services be consumed by .NET clients. According to Tim, for time-to-market reasons, the Web services needed to integrate with third-party services to locate parts or preferred distribution centers.

 

John realized his strategy of point-to-point Web services was over. The need for a whole new chapter of flexible relationship between service consumer and provider became apparent. This, together with understanding the purpose of each Web service and their dependencies, was vital. NPD was not the only customer requesting such changes.

 

John pondered how to prioritize and execute a solution:

 

•·        How can we deliver more services to our customers quickly?

•·        How can we prioritize the services that needed to be built?

•·        How can we encourage service reuse so that the cost and time required to get an application running can be reduced?

•·        How can we control the quality of service being implemented?

•·        How can we identify and improve those hard-to-integrate services?

•·        How can we identify best practices and patterns for better services?

•·        How can best practices be enforced?

•·        How can we get a handle on the entire service inventory, the infrastructure those services are required to run on, and the other services or composite applications that depend on them?

 

Without answers to these questions, John knew he couldn't deliver SOA with the promise of agility. Then John recalled reading about SOA governance a couple of years ago.

What Is SOA Governance?

"SOA governance" is a misunderstood term. Some people use the term to mean service lifecycle governance (governing from creation to implementation). Others coined it as applying runtime policies to services. But is there more to SOA governance than this?

 

SOA governance is a concept used for activities related to exercising control over services in SOA. It is an emerging concept used to address management issues that are caused by the loose coupling of services in SOA. SOA governance can be seen as an overlay on IT governance, but it often has more organizational focus than IT governance when services represent business activities.

 

To achieve SOA governance, John addressed the following:

 

  1. He collected three years worth of artifacts related to service, with a goal of understanding the end-to-end lifecycle of these assets. Artifacts included a multitude of documents from XML, Web services, DL, XLS, Excel, and Word.
  2. He established initial policies, standards, and key measurements related to the lifecycle of services and composite applications.
  3. He reviewed SOA governance mechanism software that enforces policies, decisions, and processes around end-to-end lifecycle of these artifacts.

Exploring an SOA Governance Solution

System mechanism software plays a major role in the foundation of SOA governance to enforce and automate policies across the service lifecycle. Two of the main components of this system are a registry, which acts a central index of business services, and a repository, which stores policies and other metadata related to the governance of the services.

 

By themselves, these components are insufficient. The registry and repository must be fully interoperable with each other and other SOA artifacts. They must form a comprehensive system that manages the entire SOA lifecycle.

Define Policies and Procedures

John's initial step was to define the policies for the company. This was done in conjunction with the SOA Center of Excellence (COE) to help communicate policies and other SOA-related decisions. Policies included both business and technical requirements, which helped to create a common source of information and processes. John needed to be able to answer the following questions:

 

•·        Which policy should be implemented first? What policies are needed now?

•·        Who in the organization is responsible for creating policies?

•·        How will these policies be created? How will they be communicated?

•·        Which policies can be automated?

•·        How will people within the organization discover policies?

•·        What tools will people use to follow policies?

•·        How will management get visibility into the policy compliances?

•·        What actions should be taken for policy violations?

The first step of SOA governance is to define your framework. The framework tells the organization what to consider during policy creation, communication, and enforcement relevant to the project. This governance framework then becomes your outline. Take an iterative, step-by-step or phase approach to your governance. Your initial attempt may include simple policy documentation, but your next iteration includes detailed definitions and the methods you plan to use to enforce such policies.

 

As companies move up the maturity model, they can create more enterprise-based policies and processes around shareable services. Governance becomes more important and the scope widens as SOA becomes more mainstream and reuse increases. Establish SOA goals, standards, policies, and procedures proportionate to SOA maturity.

Establish an SOA Baseline

John learned to evaluate the business impact of introducing new or changing policies against current artifacts and services already published in the registry and repository. SOA governance involves the enactment of these components: ensure that the artifacts follow policies, publish reports on results and business impacts, and dynamically associate each artifacts and its location. Having an SOA baseline allows John to see the quality of existing artifacts and highlights areas that need review. This dashboard view can be shared with senior management to provide visibility on the current state of the SOA.

 

Arm yourself with information about where to start: which policies have the highest impact on business and which are out of compliance. Focus on improving services that do not comply with policies and have the highest impact on business. Gradually bring existing services into compliance with your policies.

Establish SOA Roles and Responsibilities

John formed an SOA COE based on Gartner's recommendation. The SOA COE became the governing body and single point of coordination for SOA. Clients now have a focal point to call when they require more details on the Web services. John assigned subject matter experts, business analysts, and IT architects to the COE and assigned each a clear set of responsibilities. John also appointed a manager to chair the COE.

 

The SOA COE provides the perfect opportunity to see how business objectives can be articulated in SOA. The roles and responsibilities include these:

 

•·        Act as the SOA focal point

•·        Communicate and enforce standards

•·        Help establish reference architecture

•·        Review newly created services

•·        Encourage a high degree of service reuse

•·        Help set up policies and procedures

•·        Suggest corrective actions when a specific process is broken

•·        Define IT infrastructure to support SOA

•·        Develop clear guidelines for SOA projects

•·        Discover how to implement SOA and Web services to help increase competitive advantage

•·        Adopt proven best practices to optimize SOA

 

See how INFOR created a Center of Excellence for its System i Platform.

Continuous Governance

After the SOA baseline and COE were created, John could apply the policies accordingly to any artifacts published in the registry and repository as well as ensure continual governance over newly created services and changes to existing ones.

 

As part of policy enforcement, John can configure criteria of publication acceptance and rejection. In certain situations, he can allow publication even though the artifact is not compliant and can mark via the metadata that this artifact should not be exposed as production quality. John is aware there are exceptions to every rule; as artifacts are checked for compliance, users may want to request exception from complying with these policies. Exceptions must be managed as well.

The Foundation of SOA Governance

SOA governance cannot be purchased out of the box. However, the foundation of SOA governance is the ability to enforce and automate policies across the SOA lifecycle. A set of mechanisms can enable automation and enforcement. To do this, you need a place to store policies (policy repository) and a place to enforce them (policy enforcement point). These two locations represent where policy "lives" and where it "goes to work."

 

The SOA lifecycle consists of three stages:

  1. Design time
  2. Run time
  3. Change time

 

Regardless of the lifecycle stage, the registry and repository are the Policy Store for all the stages. Having a single context for policies enables SOA lifecycle management of policies and provides a means to establish enterprise-wide policies.

 

Stakeholder

Architect

Developer

COE

QA Testers

IT Operations

Business Users
IT Administrator

Policy Store

Registry/Repository

Policies

Change Mgt.

Publication

Policy Lifecycle

Core Security

Service Usage

Quality of Service

Auditing

Policy Enforcement Point (PEP)

Registry
Repository

Message
Transport

Management
System

Lifecycle Stages

Design
Time

Run
Time

Change
Time

 

The policy enforcement point (PEP) changes on the lifecycle stages. As illustrated above, during design time, the registry/repository itself is the PEP. During run time, the message transport system (your ESB) is the PEP. And finally, during change time, the management and security system is the PEP.

 

Design Time

•·        Architect designs a service contract or plans a service implementation.

•·        Developer searches for an existing service before building a new one.

•·        Developer requests that the SOA COE approve the creation of the service.

•·        Tester simulates a new service to execute a test plan.

 

During design time, policies such as namespace validation, schema validation, interoperability validation, approvals, document access control, audits, and resource utilization need to be enforced. If the policy repository is combined with service registry, then typical best practice is for the SOA registry/repository system to also serve as the enforcement point.

Run Time

•·        IT operations monitor a business process.

•·        IT operations confirm compliance of a service with policies (or SLA).

•·        Operations manager monitors level of service reuse.

•·        Operations manager handles service exceptions.

 

The run time system is responsible for message transport. Enterprise Service Bus (ESB) is typically used. The ESB brokers the transaction between service provider and consumer and frequently handles function, such as data transformation, reliable messaging and message queuing, security, and other operations. In Web services, the emphasis is on supporting SOAP and extensions like WS-Security. These systems can act as run time PEP.

 

Change Time

•·        Business analyst plans a change within a certain business process.

•·        IT administrator adjusts quality-of-service requirements for a service.

 

Change time governance is the act of managing services through the cycle of change. Since most services will be modified through time, this is an essential component of long-term governance. During ch

Alex Nubla
Alex Nubla is a subject matter expert specializing in Service-Oriented Architecture (SOA). He has served in a variety of technical and business roles across a broad range of industries, including banking, finance, supply chain, and healthcare to name a few. Alex' current post is as a SOA Strategic Lead and a Director for Health Net Inc.  Email. This email address is being protected from spambots. You need JavaScript enabled to view it..
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: