Error getting theme layout

Moving to a Service Oriented Architecture

Posted @ 4:00 pm by Alex Kaplinsky | Category: Technology, Web Development Process | 0 Comments

Many times clients come to us asking us to take over a “broken” website with “dubious” code that was developed by someone who is no longer with the company or by another vendor.  Often times, we are called in when there is a new look and feel or features to be added to the base. Often times this will involve changing not only the code, but the coding language (from PHP -> Python, from PERL -> PHP, etc.).  In addition, the database schema is usually not optimal / needs to be extended.  Finally a lot of those clients want to move their business to a Service Oriented approach where others (outside of the company) can use their service as a platform by interacting with it via a Service Oriented Architecture.  Salesforce.com and eBay are two great examples of companies that have transformed their business model by opening up their proprietary application via APIs.

The natural reaction of most developers I’ve ever run into is to do a “big bang relaunch” and just start from scratch.  I personally like to take things one step at a time.  I like to slowly rebuild the system step by step getting it to the point where all the transactions are done on a Service Oriented Architecture.

Step 1 – Reskin
Apply the new look and feel to the current site.  This will force you to get to know the code and all the business rules.  Each page will need to be touched, re-skinned and qa’d.  Only with this level of detail will you be able to find all the hidden gotchas in the code and the logic.  Additionally, it allows you to create and become familiar with the new front end code – which is often considerably cleaner than the legacy code we are left with.

Step 2 – Start building out new functions with SOA and new infrastructure
Keep all the old code running, but slowly build out web services with the new coding language (if switching).  When the web services are working to support the new functions, rebuild that page or add a new page consuming only the services.  This will allow you to start to move the ball forward, see what flaws there are in your architecture and roll out new features quickly while maintaining the legacy features.  The data schema should be left intact and only new constructs should be added to support new functionality.  Even if sub optimal, the main DB structure should be left for the legacy code to run on.

Step 3 – Move all functions to SOA & new infrastructure
Once the theory of building new pages on the SOA infrastructure is complete, you will have a good idea of what is working and what isn’t.  The page templating schema, services calls, etc. should all be worked out by the time you start this phase.  During this step, all the old code is replaced by new clean code consuming the services.

Step 4 – Update back end code & db for all new SOA approach
Once all the front end code has been updated, it is then time to start doing the major refactoring of the data schema.  Till this point in time, the data schema has stayed constant so that the old code will continue to work.  Once the old code is removed from the system, then the schema can be fixed if needed.   By separating the business and display logic from the data via the services  layer, the web services exposed can stay the same as the database tables are fully flushed out.

If the company wishes to move to an SOA-based business model and open their services to the outside world, steps 5 and 6 are useful.

Step 5 – Move to model of API releases and documentation for internal community of developers with standard tool kits
Once the site is consuming only your web services, it’s time to write the documentation and put in the authentication so that others can interact with your platform.  This typically involves creating documentation and making it available to the outside world – generally within the context of some sort of developer program site (developer.ebay.com, developer.salesforce.com, developer.facebook.com).  In addition, it’s usually very useful to create small “starter” toolkits in PHP, Java, .Net, PERL, Python, and Ruby for developers that they can use to plug into the system without really understanding the APIs

Step 6 – Open your API to the wider world
Once this is done,  you will have a brand new website that consumes your services.  By building out the site in this manner, you will have tested the products (the web services) you will offer to developers and the outside world.  The toolkits will provide for rapid adoption amongst developers and if you have a product others want, you should start seeing the activity.

For more information about transforming your legacy site to a modern, services-based platform, please contact us.

Leave a reply

Error getting theme layout