WIXLIB

Best Practices for Software Development Asset (SDA) Reuseprioritization, and their definitions are formalized.Ideally, eachservice definition should be driven by the requirements extractedfrom at least two separate processes. Otherwise, designing a servicebased on a single use case will probably result in a fragile,narrowly-defined service that will not be flexible enough to meet theneeds of the next set of prioritized projects.Formalizing servicedefinitions may lead to modifications in the reference model,including the identification of new services – which is just fine!This is the first step in iteratively refining the businessarchitecture.Once the service interface is specified, project teams can proceedwith detailed service design and implementation.Often, this meansassessing the current set of production applications to understandwhich aspects of the applications are candidates to support plicationcapabilities by implementing adapters that provide the necessary glueand compensation logic.Usually, these adapters are implementedbehind a component façade which may have been generated from theoriginal service definition, as specified in WSDL (or, alternatively,service operations may have been defined as methods on a componentinterface, with a WSDL document and service client proxy codegenerated from that starting point).Best Practice #2: Production Lifecycle Review PointsAs mentioned above, we need to ensure that the defined andimplemented services are properly aligned with the enterprisearchitecture, use correct implementation techniques and technologies,and provide enough supporting information to enable potentialconsumers to rapidly discover and understand them.How is thisaccomplished? By applying appropriate review points in the softwaredevelopment lifecycle (SDLC) and defining a virtual/matrixed SDAarchitectural review team to complete these reviews. 2005 LogicLibrary, Inc.9

Best Practices for Software Development Asset (SDA) ReuseWho should be on this review team? ization whose dedicated responsibility is building asuccessful SDA reuse program.Matrixed team members drawn from participating project teams.The members should have lead designer/developer skills, andtheir work on this team should be recognized and allocated as10%-20% of their job responsibility.Assignment to this teamshould be promoted as a talent-recognition award and a growthassignment for the individuals involved.A rotating membership(perhaps six to 12 months in duration) serves to train youngerdevelopers in architectural principles and then allows them tocarry that knowledge back to their project teams, increasing theoverall skill level of those teams.Consideration should also be given to including members from essfunctionality defined by a service truly reflects the enterprise’srequirements.The primary responsibility of the team is to review services underdevelopment. The objectives of this review will vary depending uponthe stage within the SDLC to which a particular service hasprogressed.At a minimum, it is recommended that organizationsreview services under development at the following points in theSDLC: Requirements complete: All business requirements are documentedand the initial service definition has been specified (ideallyas WSDL) so reviewers can validate the service against itsbusiness architectural context.Design complete: The implementation approach has been odelscompleted, relevant legacy APIs identified) to allow lication/integration architectural contexts. 2005 LogicLibrary, Inc.10

Best Practices for Software Development Asset (SDA) Reuse Implementation complete: The service has been implemented anddeployed in a test environment, with sufficient supportingdocumentation (e.g., sample client code, automated/manual testcases and test results, usage guide) to enable a potentialconsumer to understand the service and trust its quality andstability.Other review points may also be appropriate based on organizationalneeds and objectives.However, do not overwhelm development teamswith process for the sake of process.They will quickly revoltagainst jumping through seemingly arbitrary hoops.The objectiveshould be “just enough process” to provide appropriate guidance atkey points in the production and consumption lifecycles to keepthings on track.Just as right-sizing a service may be iterative,finding the right level of process control for the organization maybe iterative also. Consider starting with as “light” a process as isfeasible and adding more process steps only as needed.Appropriate tooling can greatly assist organizations in effectivelydeploying their governance processes. In fact, applying process toproduct in a pilot project is an ideal way to validate anditeratively refine the process.Industry expert Donald J. Reifer,when discussing how to implement a practical reuse program, states,“ using a pilot project to demonstrate the value added from a welldesigned and deployed infrastructure is highly encouraged. Pilotprojects force senior managers, middle managers and technologists todetermine how to take the technology and use it in concert with theorganization’s process under real budget, schedules and constraints.”1Once a service’s review has been completed, the team makes itavailable to the broader community. An asset metadata library can beof great assistance in this process since it provides automated assetvalidation and supports the steps in the review process ncludenotifications and audit trail functionality. After publication to a1Donald J. Reifer , “Implementing a Practical Reuse Program,” Component-Based Software Engineering, pp. 453-466 2005 LogicLibrary, Inc.11

Best Practices for Software Development Asset (SDA) Reusemetadata library, potential consumers are free to discover theservice and its capabilities, provide feedback and incorporate theservice into their development projects.It is likely that implementing an SDA review team will have some veryuseful side effects.Forming such a team can break downorganizational barriers, helping to mitigate any potential politicalissues associated with a reuse initiative. Simply put, creating thistype of team can eliminate the “us vs. them” mentality that oftenoccurs when governance organizations and top-down processes areimposed on development organizations. The review team also is likelyto discover additional opportunities for reusable services (andenhancements that make existing services more robust and reusable)through their informal communication. This “active discovery” of newreusable capabilities can accelerate the creation and adoption ofservices within the SOA initiative.Best Practice #3: Managing Produced Services as Internal “Products”As services begin to roll out and are consumed within projects, anorganization will rapidly reach the point where the next set ofbusiness process requirements affects one or more of the existingservices.How will the new process be supported while preserving astable operating environment for existing service consumers? Becauseservices (like components) are meant to be used in more than entalenhancement of their services over a long deployment lifetime.Ineffect, organizations planning to build a robust, stable andextensible SOA need to treat their services as “products.”What does treatingorganization? aserviceasa“product”meantoanITEach produced service must have a regular and well-definedrelease cycle.This release cycle needs to occur often enoughto meet consumer needs on a timely basis, but not so often as tochurn existing consumers.Typically, a release cycle betweenthree and six months is appropriate for most organizations, 2005 LogicLibrary, Inc.12

Best Practices for Software Development Asset (SDA) Reuse allowing them to meet new service needs without undulydisrupting existing applications.Services must preserve backward compatibility wherever possible.Deprecation techniques provide time to migrate to newer servicereleases by identifying obsolete operations and notifyingexisting consumers that the operation will be removed fromfuture releases of a service interface (also known as “end oflife-ing” in product management terms).Service providersshould offer n-1 version support at a minimum – all dasdeprecated) should be preserved intact in the current version.In addition, consider providing a “grace period” where bothservice versions are supported so consumers can make anynecessary changes to integrate the updated service.Dynamicruntime binding techniques via a Web services -basedlatebinding) can also simplify the process of migration from anolder service to a new version.A mechanism must be established by the enterprise architectureteam and service-review team to gather new requirements andenhancements for services.Consider establishing a manageandprioritize the aggregate set of business requirements for aservice.The product manager should solicit feedback fromcurrent and potential consumers of the service, consolidatethose requirements and codify them (with the assistance of theenterprise architecture team) for eventual implementation byservice development teams.Treating services as “products” has a clear impact on SDLC tools usedwithin the development teams.Some examples of these impactsinclude: Version Control.Be prepared to establish a source codebaseline within the version control repository whenever a newversion of a service is released into production (or create athread label for later use as a baseline, if needed).The 2005 LogicLibrary, Inc.13

Best Practices for Software Development Asset (SDA) Reuse service-provider team must be able to simultaneously maintain aproduction service while developing the next version of aservice.Requirements Management / Defect Tracking. Organizations need articular service on a version basis, noting the versionagainst which the requirement or defect originated and thetarget version for resolution. Most requirements management mentation.SDA Management.Maintain all “valid” versions of a servicewithin the SDA library.At a minimum, consider defining theselifecycle states for the services:o “Under Development” – Only available for the cationdevelopment team. The service is not available for generaldevelopment use.o “Production” – Generally Available (GA) version for use innew development.o “Retired” – Still in use by existing applications, but notavailable for use by new applications.o “Obsolete” – All applications should be migrated from ability and audit purposes only.Best Practice #4: Delivering Web Services to Consumers via anIntegrated Asset Metadata LibraryAd-hoc Solutions Are Not EnoughAd-hoc distribution schemes may be sufficient for managing two orthree services used by a small community, and even that is debatablesince as long-term traceability is lost if organizations do notmaintain service usage records from initial service deployment.However, ad-hoc approaches do not scale to meet the needs of largerSOA and reuse initiatives. Spreadsheets and static Web sites used todistribute services rapidly become out-of-date.Verbal, “call thearchitect” approaches to communicating knowledge about available and 2005 LogicLibrary, Inc.14

Best Practices for Software Development Asset (SDA) mationbottlenecks.And, why build a repository and distract developmentteams from their core responsibilities when there is a proven,integrated, enterprise metadata library to buy?Building a homegrown library will also likely delay an SOA implementation and otherapplication development and integration projects.A Registry Is Not a RepositoryUDDI registries are just that – a means of registering deployedservices to enable operational late binding to one of many deployedservice endpoints using a specific service (e.g., for purposes offailover, scalability and geographic distribution).Any minimalrepository capabilities in a UDDI registry are a side effect, not itsintended purpose.In short, a UDDI registry is not explicitlydesigned as a repository so it does not provide the functionality ofa true repository.For example, a UDDI registry has limited searchmetadata and cumbersome search interfaces more suited towards runtimelook-up than human interaction; is not well suited to managing otherSDA types, such as components, legacy application APIs and knowledgeassets like design patterns; and is not well integrated into velopmentenvironment (IDE) tools.To summarize, a UDDI registry is not aviable solution for meeting serious metadata repository requirements.Checklist for an Asset Metadata LibraryUltimately, the objectives in selecting and deploying an assetmetadata repository/library are to effectively govern reusable assetproduction, to make it easy for potential consumers of the assets tofind them, and to track asset usage for purposes of changemanagement, impact analysis, and ROI determination.Accordingly,consider these important features when evaluating SDA libraries: Governed and configurable asset metadata assembly and validationo Standardized metadata definitiono Per-asset-type metadata validation and enforcementConfigurable (manual vs. automatic) asset publicationo Newly defined SDAs 2005 LogicLibrary, Inc.15

Best Practices for Software Development Asset (SDA) Reuse o Updated SDAso New versions of existing SDAso Organization-defined roles and review/approval processesPassive and active distribution modeso User-based SDA subscriptionso Automated search notifications during asset creation/updatingo Multiple search modesProject and asset-specific collaborationo Discussion forumso Persistent searcheso Asset notificationsMultiple UI optionso Thin-cliento Deep IDE integrationo API-based integrationBest Practice #5: Service Usage Traceability, Impact Analysis andReturn on InvestmentFast forward a bit.Services have been built and deployed that arewell aligned with the business architecture and business processneeds.They have been published into the asset metadata library soapplication development teams can easily find them.Now, the firstapplication projects are beginning to use the services. So the reuseinitiative is finished? Not quite One of the key objectives of anSOA is to create a flexible set of reusable services that grows overtime to support all of the key business processes. This growth willinevitably result in changes to services that are already deployed(as discussed in best practice #3), making it necessary to understandwho is using which assets.In other words, consumption activitiesneed to be scoped and tracked at a project level.Project-scoped, asset-consumption tracking allows for better controlover where services are being used, enabling several criticalactivities. With this level of tracking, a service-provider team caneasily inform consuming applications of service versioning, guide 2005 LogicLibrary, Inc.16

Best Practices for Software Development Asset (SDA) Reusefuture investment towards the most heavily used services, andcalculate the value of the dollar savings resulting from the reuse ofa service and other assets (i.e., determine a return on investment(ROI) for the reuse initiative). Each of the activities supported byconsumption tracking deserves further discussion.Depending upon the business, the structure of the developmentorganization, and other factors, an organization may need more orless control over the services being used by various applicationdevelopment projects.At one extreme, an organization may want toencourage broad-based reuse of a set of core services, even going sofar as to “pre-register” specific SDAs for a development team to use.At the other extreme, there may be certain assets which are highlysensitive due to privacy concerns, legal or compliance rules, tradesecret preservation and other rationales. Limited information may bepublished about such SDAs, restricting access to sensitive artifactsuntil the necessary approvals and compliance checks have beencompleted.The SDA library should support these widely varyingconsumption models through simple configuration settings.As discussed in best practice #3, effective versioning of services iskey to producing a viable SOA over the long term; however, wellmanaged versioning is meaningless if there isn’t a way to easily andautomatically inform service consumers when new versions are plannedand deployed so they can outline a graceful, controlled roject-basedconsumption within an SDA library provides the information necessaryto proactively manage downstream consumption of versioned services.In addition, early notification allows consumers to participate inthe requirements-gathering process for a new version.Tracking which SDAs are used where quickly creates a picture of wherefuture service development and maintenance are likely to be heaviest.After all, a service used by 10 different mainline applications ismore likely to require enhancements and defect fixes than one used bya couple of analytical reporting applications.This information isinvaluable to management for resource planning and allocation.Itcan also be used to recognize and reward service-production teams 2005 LogicLibrary, Inc.17

Best Practices for Software Development Asset (SDA) Reusethat are generating heavily usedconsuming a broad range of services.servicesandgroupsthatareFinally, since enterprises are in business to make profits, costsavings are often a major

The remainder of this paper discusses five best practices within the asset-reuse lifecycle. Asset Reuse Best Practices Best Practice #1: Pragmatic Service Interface Modeling and Definition Going back to the original definition of SOA, one of the key aspects of an SOA