Platform Service Transformation: Entry 2 – Platform Architecture and ReDesign: Phase One

ArchitecturalView  

Platform Architecture and ReDesign: Phase One


2nd Entry

The purpose of this project is to unbind and unfetter a great service and product from debilitating, confusing and circuitous code. As in many cases, the code for products, is a result of many years of different code practices, developers, loss of methods in favor of “quck-fixes” to support Production. The result is a hairy, overgrown, complex, and code with nothing but dead ends in its future (in other words, non-scalable, with too many hard coded restrictions)

The Challenge is to re-design and construct a new infrastructure that IS scalable, flexible and elegant, without the User Experience changing. It may be improved, but for a more intuitive work flow’s sake, retaining the functionality on which the customer base is dependent.

The Tool Stack being used in current project for code re-factoring and re-design:
In order to transform a platform riddled with inefficient code, and work flow paths, we are consolidating DB Calls and Posts, using the following to create new service based middleware (to replace the PHP assignments): Cloud based iterations for DEV, DEVOPS, R&D, Ruby, Java, RAML for new APIs, ElastiSearch, Kibana, Jenkins, Cucumber, PHP (unraveling and re-assigning), Version One, Apache, Oracle, customized code generation, common sense, and Top-Down development and sensible deliveries for each sprint. Each of the teams (2 – Dev, UI/Biz) own their parts, and there are also intersects between the team functions for each team member. Some more than others.

CloudArchitectureMap
Example: NOT Actual

While we have spent a good bit of time re-engineering the product, we have realized, that we are limited in our demos to reflect the present level of functionality based upon the existing product. In order to fully service the needed functionality at the needed scale, we will begin development from the Top Down, rather than the discovery based Bottom Up approach. The Bottom Up approach has been useful in revealing many of the flaws, design complexities and inefficiencies, and workflows. This realization also provides the reality of NOT developing certain functional sections such as Security – already complex, into a flawed model. Once the present demo is completed to demo for execs, the functionality based upon the Bottom Up approach will be retained, but developed from the Top Down.

This shift in approach will allow implementation of complex features from a fresh start, designed to scale, and efficient.

Next Entry coming soon!

Published by

Bill Fulbright

Multiplicitous Awesomeness defined in many sets of skills.

Leave a comment