From Components To Services

420 views

Published on

Presentation made at Architect Factory 2010 -Microsoft NERD.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
420
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

From Components To Services

  1. 1. From Components to Services –An observation on paying back Technical Debt <br />Presented by Jamie Phillips<br />http://devblog.petrellyn.com<br />
  2. 2. Who is Jamie Phillips<br />Senior Software Engineer with over 12 years experience in the Telecomm, eCommerce, Finance and Healthcare industries.<br />Professional experience based on the .NET framework (versions 1.0 – 4.0)<br />Passionate about engineering and design principles.<br />Natural ability to adapt to change has lead to becoming a practicing SCRUM Master and evangelist.<br />
  3. 3. A phrase coined by Ward Cunningham to describe the effect of choosing a design that has high returns in the short term but increases complexity and maintainability in the long term.<br />Debt can be classified as:<br />Unintentional – typically where poor code has been written through ignorance or lack of experience; could be addressed with peer code reviews, etc.<br />Intentional – where design decisions are made for short-term benefit because of release dates (“we’ll sort it out in the next release”) – this is harder to resolve and often requires re-design / re-factoring.<br />What is Technical Debt?<br />
  4. 4. The fundamental basis of Software Architecture is the reduction of complexity through abstraction and separation of concerns.<br />Good use of Design Patterns and a clear Roadmap lead to good Architecture.<br />Good Software Architecture is essential to the success of a Software company.<br />Poor Software Architecture is the Achilles Heel and can be the catalyst for declining sales of a software product.<br />Thoughts on Software Architecture<br />
  5. 5. Does not mean “dumbing down”<br />Does mean the division of a large system into smaller, more manageable parts<br />Utilize the simple (and historic) theory of “Divide and Conquer”<br />Once smaller, more manageable parts are defined, system can be overhauled a piece at a time.<br />Reduction of Complexity<br />
  6. 6. Separation of concerns is achieved by applying fundamental Design Patterns (such as Dependency Injection, MVC, etc).<br />Allows for refactoring and flexibility when changing the design at a latter stage.<br />Facilitates better testing and more robust code.<br />Can become overly complex – needs to be coordinated and thought through.<br />Separation of Concerns<br />
  7. 7. Roadmaps can encompass Products, Technologies and even Enterprises.<br />Roadmaps help separate business divisions in an enterprise work towards a common goal.<br />Software Architecture is driven by both Technology and Product roadmaps.<br />Technology Roadmaps are the domain of Software Engineering – Product Roadmaps are the domain of Product Marketing / Management.<br />Roadmaps are essential for success.<br />
  8. 8. With software vendors building on their previous successes/failures:<br />Quite often the foundations are not based on the previously mentioned principles.<br />Products based on out-dated technology and / or design limitations (i.e. not scalable).<br />Tribal knowledge is lost as people move on.<br />Stating the obvious does not always take place – it can be forgotten or overlooked in the mêlée to deliver the next version.<br />So what’s new?<br />
  9. 9. Start with the exercise of creating the Product and Technology roadmaps.<br />Scrutinize the existing architecture (or lack of) with a view to identifying problem areas.<br />Get buy-in from all involved (Executives to individual contributors); otherwise the effort will be doomed from the beginning.<br />Set expectations early by planning a phased approach – few complex software products can be re-written in a short period of time.<br />It is not too late!<br />
  10. 10. “A well-placed pebble can change the course of a river.” – unknown<br />Utilize a pilot project as proof of concept.<br />Small dedicated team of domain experienced individuals.<br />Executive sponsor.<br />Minimal impact on main product code line.<br />Provide regular updates, highlighting technologies, patterns used (relate to Roadmaps for validation of work)<br />Once project is complete review the outcomes with a larger audience to familiarize people with the concepts.<br />The pebble<br />
  11. 11. Services represent capabilities:<br />SOA PrimerWhat is a Service<br />I assist the customer in selecting products<br />Facilitates invoicing the customer for purchases made.<br />Salesperson<br />Invoice Service<br />Translates<br />I deliver purchased products to customer address<br />Facilitates organizing inventory according to customer purchases.<br />Delivery Driver<br />Inventory Service<br />
  12. 12. Service Contract is the Interface implemented by the Service Class (Service classes can implement more than one Interface).<br />Operation Contract is one or more methods on the Interface that the Service Class implements.<br />Data Contract is one or more parameter types or return type related to the Operation Contract.<br />SOA PrimerAnatomy of a Service<br />IServiceA<br />Service A<br />Service A<br />Capability X<br />Capability Y<br />
  13. 13. The Service Inventory represents the sum total of all of the enterprises Services that are available for use.<br />Services are added once they become available.<br />SOA PrimerService Inventory<br />Service<br />Inventory<br />
  14. 14. Services (from a SOA perspective) bring the following to bear on the Software Architecture:<br />Organizational Agility<br />Improved Interoperability<br />Business and Technology Alignment<br />Reduced IT Burden<br />Where do Services fit in?<br />
  15. 15. Refers to the speed and ease which an organization can respond to change.<br />Maintaining an inventory of highly standardized and reusable services facilitate changing requirements.<br />Inventory is built up of standalone services that can be orchestrated in many different topologies for a variety of application uses.<br />Agility comes with maturity and size of inventory – not a one release hit.<br />Organizational Agility<br />
  16. 16. A variety of Services make up the inventory and is representative of emergent architecture.<br />Organizational Agility (cont)<br />Invoice<br />Timesheet<br />Inventory<br />Service<br />Inventory<br />New services are added as they become available<br />
  17. 17. Traditional Client-Server applications that are required to work together need periods of integration.<br />Typically, established applications were not designed to interact with each other.<br />Services, by the nature of their design, are implicitly intended to interact with other systems.<br />Services can be “orchestrated” together (from a Service Inventory) to provide the necessary functionality.<br />Improved Interoperability<br />
  18. 18. Done correctly, Services will force decoupling between various layers of a software system.<br />A system that is too tightly coupled will suffer from (to name a few):<br />High costs for maintenance – any changes that have to be made can be too complicated / too time-consuming.<br />Change is both difficult and painful; refactoring can become so difficult that it may outweigh the effort involved.<br />The more complex the system the harder it is to locate the source of an issue.<br />Improved Interoperability (cont)<br />
  19. 19. Traditional applications are not always prepared for interoperability - implicit overhead for design and testing.<br />Improved Interoperability (cont)<br />
  20. 20. Services, by their nature, are prepared for interoperability from the get-go.<br />Services can be orchestrated together to provide specific functionality.<br />Improved Interoperability (cont)<br />Service<br />Inventory<br />Service<br />Composition<br />
  21. 21. Services can be defined in terms of their business assets as opposed to simple grouping of functional capabilities.<br />Business and Technology Alignment<br />Process<br />Order<br />Business Process<br />Definition<br />Invoice<br />Inventory<br />Business Entity<br />Model<br />
  22. 22. Enterprises that offer suites of integrated applications; often carry the burden of tight coupling and spaghetti references (built up over time)<br />Reduced IT Burden<br />
  23. 23. Services are profiled and documented in a Service Inventory that can be used to build functionality for a variety of different applications.<br />The inventory reduces clutter and clearly defines the capabilities.<br />Reduced IT Burden (cont)<br />
  24. 24. Two client-server applications originally designed for different aspects of the same domain.<br />FaceForward is a client application for the Sales division; uses its own database for storing client information and sales information.<br />DispatchIt is a backend application for the Shipping division; uses its own database for storing shipping information (with some client information)<br />A tale of two productsFictional case study based on actual experiences<br />
  25. 25. A tale of two productsFictional case study based on actual experiences.In the beginning: Two separate products in their own right<br />FaceForward<br />DispatchIt<br />UI<br />UI<br />Business Logic<br />Business Logic<br />Data Access<br />Data Access<br />
  26. 26. A tale of two productsFictional case study based on actual experiences.Then: Products “merged” as an application suite.<br />FaceForward<br />DispatchIt<br />UI<br />UI<br />Business Logic<br />Business Logic<br />Data Access<br />Data Access<br />Triggers / components<br />used to<br />Synchronize common<br />data<br />
  27. 27. A tale of two productsFictional case study based on actual experiences.Migration towards Services – identify new common features.<br />FaceForward<br />DispatchIt<br />New functionality<br />takes advantage of <br />the new architecture.<br />UI<br />UI<br />Business Logic<br />Business Logic<br />Data Access<br />Data Access<br />Services<br />
  28. 28. A tale of two productsFictional case study based on actual experiences.Services begin to form basis of architecture.<br />FaceForward<br />DispatchIt<br />Over successive releases<br />more and more features<br />use the new architecture.<br />UI<br />UI<br />Business Logic<br />Business Logic<br />Data Access<br />Data Access<br />Services<br />
  29. 29. A tale of two productsFictional case study based on actual experiences.Services assume bulk of processing for thin clients.<br />FaceForward<br />DispatchIt<br />UI<br />UI<br />Services<br />
  30. 30. Services provide ideal decoupling because the service consumer only needs to know about:<br />the Service interface (Service Contract).<br />what methods (Operation Contracts) are available.<br />what parameters (Data Contracts) are needed.<br />Typically service calls are done through XML Serialization / De-Serialization, so consumers have no knowledge / dependency on the Services dependencies.<br />Services from a client perspective<br />
  31. 31. B<br />Once a component contains a reference, it exposes these references to calling components.<br />Typical Component Dependency Tree<br />Application A contains implicit references to components D and E<br />A<br />C<br />D<br />E<br />
  32. 32. Due to the nature of the Service Contract the underlying references of a Service are not exposed:<br />Services hide underlying references<br />Application A contains explicit references to the Service Proxy and has no concept of components D and E used by the Service class B.<br />A<br />B<br />D<br />E<br />
  33. 33. Phase 1 – inject the “call-through” Service between client and components.<br />Migration from Component Architectureto Services Architecture<br />Service<br />B<br />B<br />D<br />E<br />D<br />E<br />
  34. 34. Phase 2 – replace “call through” Service external references with new internal modules.<br />Migration from Component Architectureto Services Architecture<br />Service<br />Service<br />B<br />B1<br />D<br />E<br />D1<br />E1<br />
  35. 35. SOA Principles –http://www.soaprinciples.com/<br />SOA Patterns –http://www.soapatterns.org/<br />What is SOA –http://www.whatissoa.com/<br />Reference material<br />

×