Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Robert Schneider What Every Developer


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Robert Schneider What Every Developer

  1. 1. This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors What Every Software Developer Must Understand About SOA Governance SOA Systems Inc. Copyright © SOA Systems Inc. (‫‏‬ 1
  2. 2. About the Book Series Five titles currently in development for release in 2009. The Prentice Hall Service-Oriented Computing Series is the top-selling SOA book series in the world. Copyright © SOA Systems Inc. (‫‏‬ About the SOA Certified Professional Program Industry-recognized certification program for the following designations: • Certified SOA Architect • Certified SOA Analyst • Certified SOA Consultant For more information: • • Copyright © SOA Systems Inc. (‫‏‬ 2
  3. 3. Service-Oriented Architecture SOA is essentially a distinct technology architecture established in support of service-oriented solutions and therefore shaped by the demands and requirements of applying service-orientation. The fundamental characteristics of SOA are: • business-driven • vendor-agnostic • enterprise-centric • composition-centric Copyright © SOA Systems Inc. (‫‏‬ Developers and Governance Today Copyright © SOA Systems Inc. (‫‏‬ 3
  4. 4. Where Things Stand Today Despite the increasing adoption of SOA, much software design and development (and IT budget) remains focused on siloed applications: • Integration • One-off solutions • Maintenance A relatively small percentage of IT organizations are undertaking true SOA: • Of these initiatives, many are proofs-of-concept or pilots. • IT remains cautious, and focused on the bottom line. Remember: Web services <> SOA(!) Copyright © SOA Systems Inc. (‫‏‬ How Are Developers Dealing With These Realities? For those enterprises that are undertaking true SOA initiatives, developer reaction to the structure imposed by governance has been decidedly mixed: • Unhappiness with counter-agile delivery strategy. • Reluctance to face the overhead imposed by governance. • Frustration at loss of creativity and control. • Disappointment with insufficient organizational support. • Passive and active resistance to governance dictates. Copyright © SOA Systems Inc. (‫‏‬ 4
  5. 5. What Happens When Developers Shortchange Governance? The path of least resistance for many developers is simply to ignore their governance chores. This brings about: • Service proliferation • Performance issues • Confusion and duplication of effort • Exponentially more difficult governance tasks Copyright © SOA Systems Inc. (‫‏‬ What Happens When Developers Shortchange Governance? If governance responsibilities are ignored, a well-planned service inventory quickly deteriorates into a chaotic mix of de-normalized services: Copyright © SOA Systems Inc. (‫‏‬ 5
  6. 6. How Do Governance Problems Impact the Organization? Governance problems negatively impact all layers of the organization – not just IT. These issues include: • Reduced ROI • Diminished organizational agility • Increased IT burden • Degraded service to customers • A perception that SOA “isn't worth it!” In fact, governance-related issues can be the trigger that halts an SOA initiative. However: It’s not fair to place all the blame on the developer! Copyright © SOA Systems Inc. (‫‏‬ Organizational Prerequisites for Effective Governance Copyright © SOA Systems Inc. (‫‏‬ 6
  7. 7. The Organization and Governance Developers can't be expected to implement a solid governance methodology on their own. The organization must lay the foundation: • An overall SOA roadmap. • Investments in technology and methodology. • A commitment to governance as part of the SOA plan. • A recognition of the added costs and time impacts of governance. • Training and support for the development team. Copyright © SOA Systems Inc. (‫‏‬ Invest in a Center of Excellence A Center of Excellence (COE) provides a controlled, safe environment for analysts, architects, developers, and anyone else involved in the SOA initiative to learn and experiment. A COE should: • Contain a realistic mixture of hardware and software (including relevant packaged applications and governance software). • Factor in the realities of multiple domains and/or cross- departmental concerns. Consultancies can help, but IT should stay involved/in-charge. Don't forget to include governance software as part of the COE! Copyright © SOA Systems Inc. (‫‏‬ 7
  8. 8. Invest in Governance Technology It's unrealistic (and unfair) for an IT organization to expect developers to adhere to governance guidelines without any supporting technology. • A governance software investment doesn't need to “break the bank”. • High-quality open source software is available for governance initiatives. • Try before you buy; pilot projects and proofs-of-concept are great for this. Copyright © SOA Systems Inc. (‫‏‬ Incorporating Governance Into the Service Lifecycle Copyright © SOA Systems Inc. (‫‏‬ 8
  9. 9. The Service Lifecycle SOA initiatives introduce a long and thorough lifecycle into an organization. The most successful enterprises manage this lifecycle as follows: • Communicate the reason for the SOA initiative. • Point out that this initiative necessitates a new style of development lifecycle. • Train the team on the lifecycle, and their places in it. • Allocate enough time for analysis – this has a major impact on governance. • Recognize the need for new roles and responsibilities. Copyright © SOA Systems Inc. (‫‏‬ The Service Lifecycle • This is an example of a widely accepted service lifecycle. • Each phase in the lifecycle builds on what has been learned so far. • As we'll soon see, governance isn't listed as a separate step – in fact, it has a role to play in each one of these phases. • Note that different organizations may use varying terminology for their own customized lifecycle. Copyright © SOA Systems Inc. (‫‏‬ 9
  10. 10. Service Delivery & Governance Up-front analysis as part of a top-down effort reduces the eventual governance burden. The bottom-up approach results in less up-front impact, but defers burden to the governance phase. Roles SOA project roles have common relationships with specific phases of a typical SOA project delivery lifecycle. Note that this diagram does not show the service governance lifecycle. 10
  11. 11. Governance Specialist • A governance specialist is an expert in governance processes, patterns, and technology. • This role is generally required during post- testing stages, at which point the governance of services, compositions, and entire inventory architectures comes to the forefront. • However, governance specialists can also be required during any of the pre-deployment stages in order to provide guidance as to how modeling, design, or development-time decisions can impact future governance. Shaping Key Deliverables With Governance In Mind Copyright © SOA Systems Inc. (‫‏‬ 11
  12. 12. Governance Involves Much More than Just Application Code Application logic is often the first thing that comes to mind when thinking of governance. However, there are other deliverables that also have a role to play: • Schema • Contracts • Policies • Compositions Copyright © SOA Systems Inc. (‫‏‬ Contracts and Governance Contracts describe what the service will offer, and what it expects from consumers. These objects require significant governance analysis, planning, and maintenance: • Understand the impact of non backwards-compatible changes. • Be particularly wary of renaming/removing operations; additive changes aren't as dangerous. • Take advantage of Web service testing software to assist with WSDL refactoring. • Where applicable, consider applying patterns to support multiple concurrent versions of a contract. Copyright © SOA Systems Inc. (‫‏‬ 12
  13. 13. Policies and Governance Policies let service designers and developers provide a wide variety of guidelines regarding service behavior. Special governance concerns include: • Hierarchical nature introduces the possibility of conflict. • Often assembled out of multiple assertions. • Can be attached to different portions of the Web service contract. • Operator composition introduces complexity. • Difficult to get a single, authoritative view of policy landscape. For all of these reasons, it might be wise to reduce governance risk by centralizing policies rather than maintaining them in individual services. Copyright © SOA Systems Inc. (‫‏‬ Policies and Governance Policy assertions that apply to multiple services can be abstracted into separate policy definition documents or service agents that are part of an inventory-wide policy enforcement framework. Copyright © SOA Systems Inc. (‫‏‬ 13
  14. 14. Schema and Governance Accurate, well-governed schema are an essential foundation for Web services (and SOA). Schema impacts governance as follows: • Schema extensions and overrides can complicate governance efforts. • XML Schema alterations can have the same impact as major relational database schema modifications. • When XML Schema is generated from a database schema, the database platform may provide a certain amount of governance infrastructure. • However, automatically generated XML Schema can get out of sync with the database should alterations be made to the underlying table structures. Since schema is so vital to effective governance efforts, there are strong arguments in favor of applying a centralization pattern. Copyright © SOA Systems Inc. (‫‏‬ Schema and Governance Schemas can be designed and implemented independently from the service capabilities that utilize them to represent the structure and typing of message content. Copyright © SOA Systems Inc. (‫‏‬ 14
  15. 15. Compositions and Governance Recall from earlier that compositions are one of the primary reasons for undertaking an SOA initiative. Special governance challenges include: • Compositions are made up of many moving parts. Downtime to any single part shuts down the entire composition. • You may not even own all of the services that are part of your composition. • You may not be able to predict all of the compositions that will be utilized. • Compositions often make use of 3rd party technologies (such as Enterprise Service Buses (ESB), Message queues, and so on). These all must be governed as well. These potential headaches highlight the need for solid testing and governance technology (in support of an effective methodology) as part of your environment. Copyright © SOA Systems Inc. (‫‏‬ Governance and Software Development Copyright © SOA Systems Inc. (‫‏‬ 15
  16. 16. Governance, Developers and the Creative Process Cultural and other political rationales are often the hidden reasons behind resistance to governance efforts. • Standards are much more important in an SOA initiative. • By necessity, this places limits on developer creativity. • This is especially true for developers whose primary experience has been writing siloed applications. However - it's important to remember that creativity and developer ingenuity can be fostered by SOA, especially regarding assembling unique compositions. Copyright © SOA Systems Inc. (‫‏‬ Making it Easy for Developers to Adopt Governance In spite of the perceived limitations of governance on creativity and flexibility, most developers want their SOA initiative to succeed. However, this won't happen unless certain preconditions are met: • Set up (and document!) a well planned set of processes. • Make service profiles an integral part of the SOA initiative. • Reward developers who contribute to the service profile. • Restrict access to design documents, source code, and so on. • Enforce governance compliance for outsourced development teams. • Reduce the governance burden on developers, as described next. Copyright © SOA Systems Inc. (‫‏‬ 16
  17. 17. Reducing the Governance Burden on Developers Developers are naturally sceptical about SOA and its related governance requirements. There are a few steps that can be taken to help address these concerns: • Construct the organizational foundation (people, process, technology) as described earlier. • Don’t punish developers for the overhead mandated by adherence to solid SOA design and governance methodologies. • Maintain appropriate staffing levels in related areas (e.g. architecture, testing/QA) to facilitate developer productivity. • Recognize the need for new skill sets (e.g. service and policy custodians, technical communications specialists, etc.) • Educate development management personnel about the likelihood of cross- departmental support requirements. Copyright © SOA Systems Inc. (‫‏‬ Measure Governance Compliance The most well-designed SOA methodology and governance processes won't be worth much if you don't measure compliance (as well as problems caused by non-compliance). Fortunately, modern governance technology lets you: • Predict hotspots, version incompatibilities, business policy inconsistencies, and so on. • Notify administrators when trouble arises (or is likely to arise). • Measure the impact of a change to a given service. • Track re-use, govern your inventory, and so on. Copyright © SOA Systems Inc. (‫‏‬ 17
  18. 18. Providing Incentives to Developers Some organizations adopt a carrot-and-stick approach to coaxing developers to follow governance guidelines. • Flexible compensation plans. • Recognizing that “number of lines of code written” isn’t (necessarily) a valid productivity metric anymore. • Reward developers for reusing others' work. • Reward developers for writing reusable services. • Penalize developers who unnecessarily create new services (or otherwise violate governance standards). Copyright © SOA Systems Inc. (‫‏‬ Q&A SOA Systems Inc. SOA Training SOA Certification SOA Books SOA Magazine SOA Patterns Updates Contact ( Copyright © SOA Systems Inc. (‫‏‬ 18