1. Specialists in Service Oriented
Application Modernization
Opposites Attract,
SOA, Model Driven
Architecture and Agile
April 12, 2011
Denzil Wasson
(dwasson@everware-cbdi.com)
www.everware-cbdi.com
Imagine a whole portfolio of this lifecycle pattern (or anti-pattern when we think of what we are being tasked for)Is trying to do this in shorter agile bursts going to leave us permanently in 1 of the 3 bad zones?How do services get worked into this model? What about developing services? – the impact of developing services in this manner could amplify the disruption
Key wordsCloud First, Shared, Modular, Shortened Cycle, Managed, Consolidated, CollaborationShared services – think of various layers of granularity e.g. utility – payment processing, addressing core – case management, account management, content management business – child welfare case management, justice case management etc..Modernized Software Development Process – this and the next point about procurement are closely related – they would both have to structured differently to be able to specify, acquire and build modular components of solutions which can assembled via SOA
We see a convergence rather than a set of distinct capabilities – so rather than just thinking about doing virtualization or SOA or cloud or agile or MDA we submit that the combination of these techniques, methods and architectures converge to give us a truly agile architecture managed by an agile IT organization in support of an agile businessLegacy shown at the bottom left illustrates a typical stovepipe architecture which is usually structured along organizational lines and sometimes specific business process. This architecture is challenging to integrate and maintain and usually has redundant functionality. Further challenges may result due to legacy platform constraints e.g. no service orientation, inability to deliver to modern channels, skills availability.The modernized portfolio on the bottom right is a cloud ready, service oriented non-redundant set of modular capabilities that can be acquired, structured, orchestrated as needed by the organization’s changing requirements.
From a budgeting, investment, staffing and timing point of view we expect that the iterative agile method would provide us a smoother delivery curve that delivers early and is in continual delivery mode over the life of the solution. This is much more predictable and thus manageable and the continuous delivery model enhances the business to IT relationship, providing feedback that further optimizes the delivery process.Although agile by itself is a good thing – it is difficult to achieve with our traditional approaches to architecture (which is not as modular as SOA) and implementation (which is a very labor intensive and error prone process).So in addition we put forward the multipliers at the bottom that should be applied to really achieve the vision of an agile portfolio
The iterative, continuous delivery and shortened feedback loop of agile all relate directly to the early delivery, light scoping, modularity, manageability, budgeting flexibility and enhanced acquisition models within OMBs 25 point planLong term predictive approaches have proven to be somewhat unreliable and don’t accommodate changing requirements, priorities and circumstances very well. In addition traditional waterfall methods have distinct phases where the focus tends to be on producing that phases’ set of artifacts and only later in the cycle is the actual software one of those deliverables. In contrast agile has a much shorter time horizon, ‘the sprint’ (1-4 weeks) and every sprint is expected to produce some working software that can be demonstrated (although not necessarily released to production).Scrum master is a facilitative role who ensures that the team remains productive by ensuring the team remain true to their chosen process, escalating and handling blockages, preventing outside distractions / interference, Product owner ensures the ROI of the product by collaboratively defining features, prioritizing delivery, evaluating the software (demos) and accepting or rejecting work doneThe team is a cross-functional ‘right sized’ usually 10 or less , self organizing team that is empowered to do anything they can within the bounds of the project to achieve the sprint goalsScrum starts with planning to produce a product backlog usually in the form of user stories. Each sprint starts with a planning phase that selects a prioritized scope of features that are meaningful to the product owner and achievable to the team from the product backlog to become the sprint backlog. The Scrum master organizes and facilitates daily stand-up meetings to understand progress on sprint goals and to uncover any blockage to the team. The end of a sprint produces ‘potentially shippable’ software that may be released to production as decided and scheduled by the product owner.
Service oriented architecture sets the stage for standards based sharing, well define modularity , sharing and the ability to build cloud based solutions. Service orientation is a key element of building an agile portfolio since the traditional breakage points of integrated solutions are formalized and managedIt is also important to understand that SOA is an important insulator when it comes to COTS consumption and if designed correctly allows you to leverage COTS (even cloud based) without being too dependent on the particular provider
The term MDA and MDD are often interchanged – we see MDD as more holistic then MDA since MDA is concerned with the definition of a PIM and its conversion to PSM and then to an implementation. However we see MDD as more encompassing and the potential for the models to be used to produce the implementation as well as other needed artifacts for testing and documentation.While not a new concept, MDD is not widely practiced and unfortunately the agile mantra of ‘working software above all else’ seems to drive teams to ‘code first’ – however in MDD not only are the models the code but they also accelerate the production of working software, facilitate communication about the software, enhance the quality of the software and even facilitate the maintenance and refactoring efforts that often go along with agile development. Oh and they allow you to run an agile practice that actually produces documentation as a natural side effect of the coding since much of the coding is done in model form.
Knowledge discovery and patterns are important concepts that we use in our practice. Since most organizations have legacy applications that do support their missions,, there is usually a lot of knowledge codified into those applications. The goal of knowledge discovery is to harvest and capture that knowledge in a way that is useful to the organization – not only for any transitional efforts (i.e. we don’t want to just recodify it again) but in a way that is useful to the ongoing evolution of the organization and its supporting services and solutions.We leverage patterns as an important accelerator in our reverse engineering processes, our knowledge discovery processes and our forward engineering practices. Since many legacy systems exhibit repeating architecture and design patterns, we can identify the patterns and then focus solely on the unique aspects of the implementation, the same goes for the forward engineering from specification onwards. Essentially it allows us to focus on the 20-30 % of the system that really matters rather than the noise of the implementation paradigm.
So how do we get from the situation we have to the vision painted by the 25 point plan. For the legacy systems we propose service oriented modernization. An important note is that this is not just a $ amount per line re-platforming – which recreates the same problems in in a new technology. This is an agile restructuring (and possibly re-platforming) process that includes knowledge discovery with the objective of modernizing the solutions to SOA and modernizing the IT organization to an agile continuous delivery model that leverages MDD
The modernization framework follows 5 high level phases:Assess- Plan-Analyze-Deliver-Evolve – Note however that each iteration of the modernization framework covers all of the phases so rapid delivery of working modernized services and solution is ensured.The organization context (the circle in the center) of each iteration is also modernized as needs be as part of the process.
The SAE Process provides a consistent view of the activities required to plan, architect, enable, deliver and manage SOA based solutions. In considering how the SAE Process will evolve to accommodate modernization we recommend that the basic model that separates consumer and provider is entirely appropriate because the Target Architecture is going to be intrinsically SOA based. The top level SAE2 Process Model identifies process disciplines and their primary dependencies.
Mature teams can overlap sprints to get a kick start on specifications
In this case study the preferred legacy solution was restructured to support a distributed SOA solution. The legacy portions remain on the CICS Mainframe platform but are exposed via ESB hosted proxies to a distributed J2EE platform for the channels of the solution. Importantly the implementation of the services can easily be moved from the MF when desired without impacting the solutions using the services.
The SOA outcome not only modernizes the selected slice of the portfolio but also establishes the foundation of the future SOA, including some reusable core and utility services.The location management pieces was a Mainframe based green screen application while the logistics piece was a client server application with mainframe based CICS servers. The new technical architecture is IBM SOA and J2EE based hosted on the mainframe.
- Focus less on how – more on the outcome – simplifyScenario is a re-usable pattern – Outcome specific to this case studyConsider this scenario if…applicability
Major cotsDocumentum, Drools, Xpression, Ldap, XMl diff, exalead cloud viewThis was a significant business process that covered the submission of information from the constituent, the validation the information, case assignment and examination, formal correspondence and final acceptance or rejection of the case.The end result is a flexible rules based SOA that is cloud ready and can leverage COTS capabilities that are in house or cloud based.