From Components to Services –An observation on paying back Technical Debt <br />Presented by Jamie Phillips<br />http://de...
Who is Jamie Phillips<br />Senior Software Engineer with over 12 years experience in the Telecomm, eCommerce, Finance and ...
A phrase coined by Ward Cunningham to describe the effect of choosing a design that has high returns in the short term but...
The fundamental basis of Software Architecture is the reduction of complexity through abstraction and separation of concer...
Does not mean “dumbing down”<br />Does mean the division of a large system into smaller, more manageable parts<br />Utiliz...
Separation of concerns is achieved by applying fundamental Design Patterns (such as Dependency Injection, MVC, etc).<br />...
Roadmaps can encompass Products, Technologies and even Enterprises.<br />Roadmaps help separate business divisions in an e...
With software vendors building on their previous successes/failures:<br />Quite often the foundations are not based on the...
Start with the exercise of creating the Product and Technology roadmaps.<br />Scrutinize the existing architecture (or lac...
“A well-placed pebble can change the course of a river.” – unknown<br />Utilize a pilot project as proof of concept.<br />...
Services represent capabilities:<br />SOA PrimerWhat is a Service<br />I assist the customer in selecting products<br />Fa...
Service Contract is the Interface implemented by the Service Class (Service classes can implement more than one Interface)...
The Service Inventory represents the sum total of all of the enterprises Services that are available for use.<br />Service...
Services (from a SOA perspective) bring the following to bear on the Software Architecture:<br />Organizational Agility<br...
Refers to the speed and ease which an organization can respond to change.<br />Maintaining an inventory of highly standard...
A variety of Services make up the inventory and is representative of emergent architecture.<br />Organizational Agility (c...
Traditional Client-Server applications that are required to work together need periods of integration.<br />Typically, est...
Done correctly, Services will force decoupling between various layers of a software system.<br />A system that is too tigh...
Traditional applications are not always prepared for interoperability - implicit overhead for design and testing.<br />Imp...
Services, by their nature, are prepared for interoperability from the get-go.<br />Services can be orchestrated together t...
Services can be defined in terms of their business assets as opposed to simple grouping of functional capabilities.<br />B...
Enterprises that offer suites of integrated applications; often carry the burden of tight coupling and spaghetti reference...
Services are profiled and documented in a Service Inventory that can be used to build functionality for a variety of diffe...
Two client-server applications originally designed for different aspects of the same domain.<br />FaceForward is a client ...
A tale of two productsFictional case study based on actual experiences.In the beginning: Two separate products in their ow...
A tale of two productsFictional case study based on actual experiences.Then: Products “merged” as an application suite.<br...
A tale of two productsFictional case study based on actual experiences.Migration towards Services – identify new common fe...
A tale of two productsFictional case study based on actual experiences.Services begin to form basis of architecture.<br />...
A tale of two productsFictional case study based on actual experiences.Services assume bulk of processing for thin clients...
Services provide ideal decoupling because the service consumer only needs to know about:<br />the Service interface (Servi...
B<br />Once a component contains a reference, it exposes these references to calling components.<br />Typical Component De...
Due to the nature of the Service Contract the underlying references of a Service are not exposed:<br />Services hide under...
Phase 1 – inject the “call-through” Service between client and components.<br />Migration from Component Architectureto Se...
Phase 2 – replace “call through” Service external references with new internal modules.<br />Migration from Component Arch...
SOA Principles –http://www.soaprinciples.com/<br />SOA Patterns –http://www.soapatterns.org/<br />What is SOA –http://www....
Upcoming SlideShare
Loading in …5
×

From Components To Services

394 views
334 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
394
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 />

×