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:
- 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.
- He established initial policies, standards, and key measurements related to the lifecycle of services and composite applications.
- 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:
- Design time
- Run time
- 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 |
| Policy Store | Registry/Repository | ||
| Policies | Change Mgt. Publication Policy Lifecycle | Core Security Service Usage Quality of Service | Auditing |
| Policy Enforcement Point (PEP) | Registry | Message | Management |
| Lifecycle Stages | Design | Run | Change |
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
More 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.
TRY 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.
Forms 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.
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:
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.
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:
LATEST COMMENTS
MC Press Online