Organic Planning

1,859 views

Published on

Towards a new theory of service design

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,859
On SlideShare
0
From Embeds
0
Number of Embeds
59
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Organic Planning

  1. 1. Organic Planning Richard Veryard
  2. 2. About this presentation <ul><li>For many years I’ve been presenting ideas about service design and organic planning, based on the recent work of Christopher Alexander. </li></ul><ul><li>Some of these ideas have been picked up by experts in various fields, including SOA and enterprise architecture. </li></ul><ul><li>The current presentation represents work-in-progress towards a longer and more systematic treatment of these ideas. </li></ul>
  3. 3. Parallels between Town Planning and System Design <ul><li>The distribution of design. </li></ul><ul><ul><li>Detailed design decisions are taken within different organizations, each following its own agenda (e.g. commercial or political goals). </li></ul></ul><ul><li>The need for progressive improvement. </li></ul><ul><ul><li>Each design increment should not only make local improvements, but should have a positive effect on the whole. </li></ul></ul><ul><li>The constancy of change. </li></ul><ul><ul><li>Elements of the whole are constantly being redesigned and reconfigured, and new elements are constantly being added. Structures must evolve in robust ways. </li></ul></ul><ul><li>The recursive nature of the architecture. </li></ul><ul><ul><li>Similar design tasks must be carried out at different scales (levels of granularity). </li></ul></ul>
  4. 4. Principle of Wholeness <ul><li>“ Each new act of construction must create a continuous structure of wholes around itself.” </li></ul><ul><li>(Christopher Alexander) </li></ul><ul><li>A designer tasked with constructing something of scale X must pay attention to three scales </li></ul><ul><ul><li>larger than X </li></ul></ul><ul><ul><li>same as X </li></ul></ul><ul><ul><li>and smaller than X </li></ul></ul>
  5. 5. Towards A New Theory … <ul><li>Three design rules for SOA </li></ul><ul><li>Each service should contribute to some larger-scale “whole” service. </li></ul><ul><li>Each service should have clean boundaries with other services of the same scale as itself. </li></ul><ul><li>Each service should be supported by a series of smaller-scale services. </li></ul><ul><li>Rotational Symmetry </li></ul><ul><li>Entity-Based Life-Cycle – including all events that alter the identity or status of the entity </li></ul><ul><li>Process-Based Closed Feedback Loop – including all activities that establish stability / equilibrium between independent elements. </li></ul><ul><li>Rule-Based Open Learning Loop – including all activities that allow the rule/policy to be reviewed and improved </li></ul><ul><li>Service Type Basis of Symmetry </li></ul>
  6. 6. Example – Improving HR Systems – Step 1 <ul><li>The office equipment application obtains employee data direct from the employee database. </li></ul><ul><li>The office equipment application is given direct access to employee data. This means it has to be subject to higher levels of privacy and security protection than it otherwise needs. And it is affected by any local changes in the HR database systems. </li></ul><ul><li>The mechanism for providing office equipment services to non-employees is not properly defined. </li></ul><ul><li>Provision of services to non-employees is adhoc and often inconsistent. Sometimes non-employees get a better service than employees, sometimes they don’t get any service at all. In a few cases, non-employees have been added to the HR employee database, with status codes to denote that they are not real employees. This makes the HR systems more complex. There is a risk of processing error if HR applications fail to check the status code properly. </li></ul>Employee Database HR Systems Office Equipment Service Contractor Database
  7. 7. Example – Improving HR Systems – Step 2 <ul><li>An employee context service is introduced, to shield the office equipment service from the HR database. </li></ul><ul><li>This initially gets data direct from the HR database. When appropriate web services are provided by HR systems, these will be used instead. </li></ul><ul><li>This service can then be used by other applications/services as well, thus gradually reducing the number of applications/services with direct access to the HR database. </li></ul>Employee Database HR Systems Employee Context Service Office Equipment Service Contractor Database
  8. 8. Example – Improving HR Systems – Step 3 <ul><li>An equivalent service is created for establishing Contractor Context. </li></ul><ul><li>This initially gets its data from a local file of approved contractors. </li></ul><ul><li>We can now clean the non-employees out of the HR database, which makes it simpler and more reliable. </li></ul><ul><li>The contractor context service allows a range of office services to be provided to contractors in a consistent and controlled way. </li></ul>Employee Database HR Systems Employee Context Service Office Equipment Service Office Worker Context Service Contractor Context Service Contractor Database
  9. 9. Example – Improving HR Systems – Step 4 <ul><li>The Contractor Context service now gets its data by remote access to the contractor’s systems. </li></ul><ul><li>This means that if a member of contracting staff changes employment status with the contracting company, this can be immediately reflected in office services. </li></ul>Employee Database HR Systems Employee Context Service Office Equipment Service Office Worker Context Service Contractor Context Service Employee Database HR Systems Contractor Systems
  10. 10. Service Design Orientation <ul><li>To create a continuous web of interoperating services, each act of servicing must pay attention to four design directions. </li></ul>MyService upwards sideways inwards downwards
  11. 11. Service Design - Upwards <ul><li>MyService must contribute (in multiple ways) to some defined larger-scale service/packages. </li></ul><ul><ul><li>Business process / orchestration </li></ul></ul><ul><ul><li>Closed feedback loop </li></ul></ul><ul><ul><li>Entity supertype </li></ul></ul><ul><ul><li>Entity lifecycle </li></ul></ul><ul><ul><li>Knowledge learning cycle </li></ul></ul>MyService upwards
  12. 12. Service Design - Sideways <ul><li>MyService must interoperate with sibling services. </li></ul><ul><li>No “negative space” between services – this implies some sense of completeness of the service together with its siblings when viewed from above </li></ul><ul><li>No conflict between neighboring services – this implies some architectural “deconflicting” effort </li></ul>sideways MyService sideways
  13. 13. Service Design - Downwards <ul><li>MyService must use or be decomposed into lower-level services in some meaningful way. </li></ul><ul><ul><li>Process-based separation (e.g. Orchestration / Steps) </li></ul></ul><ul><ul><li>Object-based separation </li></ul></ul><ul><ul><li>Responsibility-based separation (e.g. Action, Exception, Data, Context, Policy) </li></ul></ul>MyService downwards
  14. 14. Service Design - Inwards <ul><li>How does MyService add value by transforming the input services to the output services? </li></ul><ul><li>MyService must perform an accurate and complete transformation from input into output – functional composition. </li></ul>MyService inwards
  15. 15. The Lankhorst Version Upwards Towards the elements that are supported by it Inwards Towards the internal composition of the element Downwards Towards its realization by other elements Sideways Towards peer elements with which is cooperates Marc Lankhorst et al, Enterprise Architecture at Work (Springer, 2005) pp.129-130, pp 170-171. Tony Bidgood, ArchiMate: A Standard for Enterprise System Modelling (CBDI Journal, August 2008) Composition Realization Cooperation Support Cooperation
  16. 16. The Bell Version <ul><li>Look in the box: Analyze internal service composition and capabilities. </li></ul><ul><li>Look above the box: Study best practices, service governance, and service life cycle disciplines. </li></ul><ul><li>Look below the box: Perform separation of concerns, loose coupling, and granularity analysis. </li></ul><ul><li>Look out of the box: Analyze interoperability, distribution, and relationships of services. </li></ul>Michael Bell, SOA Modeling Patterns for Service Oriented Discovery and Analysis, Wiley 2010.
  17. 17. Summary: Towards a Continuous Fabric of Services <ul><li>The service-oriented business is configured as a continuous fabric of services – “the corporate web”. This can never be achieved in one large ambitious project. It is achieved progressively through a continuous stream of small and medium projects. </li></ul><ul><li>In the organic planning approach, order and coherence emerges from distributed activity, with no central design authority. However, some governance is needed to maintain architectural order. Each unit of procurement, development or maintenance activity is regarded as a project. Project outputs are constituted as services. Each project contributes something positive to the emerging corporate web of services. </li></ul><ul><li>SOA Governance is required to ensure that each project satisfies the global demands of the corporate web, and ensure that there is a well-balanced mix of projects – different types as well as different scales (large, medium and small). </li></ul>
  18. 18. References <ul><li>Christopher Alexander, A New Theory of Urban Design (1987) </li></ul><ul><li>Christopher Alexander, The Nature of Order (2002) </li></ul><ul><li>Michael Bell, SOA Modeling Patterns for Service Oriented Discovery and Analysis (Wiley 2010) </li></ul><ul><li>Tony Bidgood, ArchiMate: A Standard for Enterprise System Modelling (CBDI Journal, August 2008) </li></ul><ul><li>Marc Lankhorst et al, Enterprise Architecture at Work (Springer, 2005) </li></ul><ul><li>Richard Veryard, Component-Based Business: Plug and Play (Springer 2001) </li></ul><ul><li>Richard Veryard, Business Driven SOA (CBDI Journal, May 2004) </li></ul><ul><li>Richard Veryard, Business Driven SOA 2 (CBDI Journal, June 2004) </li></ul><ul><li>Richard Veryard & Philip Boxer, Metropolis and SOA Governance. Part 1: Towards the Agile Metropolis (Microsoft Architecture Journal 5) </li></ul><ul><li>Philip Boxer & Richard Veryard, Metropolis and SOA Governance. Part 2: Taking Governance to the Edge (Microsoft Architecture Journal 6) </li></ul><ul><li>http:// delicious.com/richardveryard/governance </li></ul>
  19. 19. If you were intrigued by this presentation … <ul><li>For more of my stuff … </li></ul><ul><li>… read my blog </li></ul><ul><li>RVsoapbox.BlogSpot.com </li></ul><ul><li>… browse my articles </li></ul><ul><li>delicious.com/richardveryard </li></ul><ul><li>For more on SOA … </li></ul><ul><li>… read the SOA Process blog </li></ul><ul><li>SOAprocess.BlogSpot.com </li></ul><ul><li>… and join the CBDI Forum </li></ul><ul><li>Bronze membership is free </li></ul><ul><li>Gold membership provides access to all articles </li></ul><ul><li>Platinum membership provides full access to knowledgebase </li></ul>www.cbdiforum.com

×