Download Presentation


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Download Presentation

  1. 1. Montages Partner Meeting - Zurich – Nov 4-5, 2006 Towards Agile Architecture-Centric MDSD at Credit Suisse Jorn Bettin [email_address]
  2. 2. Relation to MAMA MAMA Service Methodology MAMA Service Methodology MAMA Service Methodology MAMA Service Methodology Model Driven Consulting Model Driven Analysis Model Driven Engineering Transition Consulting Business Analysis Framework Engineering Requirements Consulting Process Analysis Change Consulting Fast Prototyping Modelling Architecture Quality Analysis
  3. 3. Context
  4. 4. Context Overview <ul><li>Credit Suisse “platinum priority” [top-10] projects </li></ul><ul><li>Quarterly cycle of software deployments into production </li></ul><ul><li>Waterfall software development process </li></ul><ul><li>Often more than 12 months from enhancement request to availability of a new feature </li></ul><ul><li>Parallel development of several future releases even if only one release is in production </li></ul><ul><li>Informal software design specifications where models are included on an ad-hoc basis </li></ul><ul><li>Role of models is limited to visualization of tentative design ideas </li></ul><ul><li>Poor modularization and encapsulation within and between systems </li></ul>
  5. 5. Parallel Development R1.1 R4.1 R1 R1.1 R2 R3 R4 R4.1 R2 R3 R4 R1 Quarterly production deployments Two to three releases under development at any one point in time
  6. 6. Poor Modularization <ul><li>No clear partitioning of functional modules </li></ul><ul><li>No clearly identifiable component interfaces in code </li></ul><ul><li>No enforcement of hard limits on the level coupling between systems </li></ul><ul><li>Limited partitioning of application infrastructure code </li></ul><ul><li>Violations of layering principles and circular dependencies in code base </li></ul><ul><li>This is a common scenario in large software-intensive organizations, and the situation at Credit Suisse is by no means exceptional </li></ul><ul><li><sample picture goes here> </li></ul>
  7. 7. Dependency Management <ul><li>Poor dependency management is one of the most frequently encountered quality issues in enterprise software . Since there exists no quick fix for this issue, the motivation to address the problem usually only kicks in once maintenance costs and time to market are critically affected. </li></ul><ul><li>The most commonly suggested “solution” at that point is a “rewrite” of the system. Rewriting a software system from scratch is a high risk undertaking . In particular there is a significant risk that the new system will over time accumulate similar dependencies to the dependencies of the old system. Then the envisaged target architecture remains a theoretical “Powerpoint Architecture”. </li></ul><ul><li>Incremental software architecture evolution can be a less risky alternative to rewriting a system. Yet this alternative is only practical when the process is supported by specialized tools for dependency management. For a large system the complete journey to a sufficiently maintainable and modularized target architecture may take 12 months or more. The most effective approach relies on a combination of reactive dependency management and proactive dependency management. </li></ul>
  8. 8. Dependency Management - the Raw Numbers <ul><li>Careless construction of point-to-point interfaces is a deadly trap that looks harmless at first, and then “grows on you” with quadratically increasing impact </li></ul>Don’t get lost in micro design and low-level design patterns. The simplest preventative measure to curb spurious complexity without being prescriptive at the micro-level (software developers don’t tend to like that, and most like to have a degree of artistic freedom) is to consistently make use of a nested subsystem structure in the logical model of your system architecture . This strategy works regardless of the quality of design and implementation at the micro-level, as long as you deploy a mechanism that physically enforces this [one single] design rule.
  9. 9. Solution
  10. 10. Solution Overview <ul><li>Paying sufficient attention to selecting the most effective sequence for improvements </li></ul><ul><li>Introducing agility into the software development process </li></ul><ul><li>Mentoring in the art of modularization and encapsulation </li></ul><ul><li>Preparing for Architecture-Centric Model Driven Software Development </li></ul><ul><li>Core objective is knowledge transfer to Credit Suisse staff </li></ul>
  11. 11. Sequence of Improvements <ul><li>1. Identification of major architectural violations in the code base with the help of dependency management tools </li></ul><ul><li>2. Introduction of the principles of fully externalized component interface specifications </li></ul><ul><li>3. Partitioning of the domain layer into a set of encapsulated, collaborating components </li></ul><ul><li>4. Introducing monthly validation of software under construction by stakeholders and end users to weaken the shortcomings of the waterfall approach </li></ul><ul><li>5. Reverse engineering of use case scenarios from informal requirements specifications to enable requirements management </li></ul><ul><li>6. Allowed new requirements to enter the development cycle on a monthly basis through a managed, formal process </li></ul><ul><li>7. Visualization of component interface specifications in UML </li></ul><ul><li>8. Tool assisted architecture quality management </li></ul><ul><li>Next Steps </li></ul><ul><li>9. Roll out of these new techniques to further projects </li></ul><ul><li>10. Enforce principles of fully externalized component interface specifications in further architectural layers </li></ul><ul><li>11. Use UML model driven generation to move from code centric development to architecture centric development </li></ul>
  12. 12. Introducing Agility <ul><li>When a waterfall like process is still in place, the biggest bang for the buck is usually achieved by introducing iterations that are concluded by formal validation of software under construction by stakeholders and end users </li></ul><ul><li>This enables to realign the project with the latest business priorities on a monthly basis, and prevents the project from getting more than a month away from a point of consensus </li></ul><ul><li>Before iterative requirements management is established, there is little to be gained by architectural improvements in the code base </li></ul><ul><li>In large programs and projects it is essential that requirements management is a formal process where all decisions regarding scope and priorities are recorded </li></ul><ul><li>Timeboxed iterations of constant duration are well suited to establish a regular rhythm of software delivery in a large team </li></ul><ul><li>The full potential of iterative requirements management is only reached when formal scope trading with project stakeholders is used to determine the priorities of the next iteration </li></ul>
  13. 13. Modularization Component 1 Component 2 Component 3 How big is the type set exposed in the component interface? Where is this dependent type set defined? How many dependencies exist? Are there any circular dependencies?
  14. 14. The Principles of Fully Externalized Interface Specifications <ul><li>The types exposed in a Component interface are all defined in a Component [Collaboration] Platform that resides outside the Component . Thus a Component Platform exposes the types contained within it, and is therefore fundamentally different from a Component. </li></ul><ul><li>Components may either contain realizations of the types used in their interface, or they may obtain access to instances of the types used in their interface via an interface of the corresponding Component Platform. </li></ul><ul><li>The interfaces of several Components within an architectural layer share a common Component Platform . </li></ul><ul><li>For convenience purposes, a Component Platform may be defined as a union of other Component Platforms. </li></ul><ul><li>The level of abstraction can be raised by constructing a Component Platform from a group of collaborating Components and their common Component Platform , and using a façade and any required helper classes to lift the API. </li></ul>
  15. 15. Encapsulation & Nested Components
  16. 16. Dependency Management is required at all Levels of Abstraction
  17. 17. Architecture-Centric MDSD (1/2) <ul><li>In all those cases where there is a lack of deep business domain expertise, and also in those scenarios where 90% of the domain amounts to CRUD functionality for maintaining business entities realized with an implementation technology stack of T 1 , T 2 , … T n , there is no point in trying to develop a DSL motivated by the business domain. </li></ul><ul><ul><li>This simply means that the main DSL could be a tailored type of &quot;UML class diagram&quot; that takes into account local constraints and limitations within the enterprise architecture of an organization. </li></ul></ul><ul><ul><li>Further DSLs may come into play to describe workflow, visual characteristics and behavior of business entities on the user interface, mappings to technologies T 1 , T 2 , … T n , structures from existing legacy systems , and so on. This leads to small “aspectual” DSLs that can be woven together in a template language [that bridges the meta models of the DSLs at generation time] and in code generation templates. </li></ul></ul><ul><li>DSLs can provide an implementation technology free front-end to capture the majority of application requirements in a formal notation that can automatically be converted into executable application code. The remaining 10-20% of requirements that amount to non-templatizable business logic are often best implemented in a traditional general purpose language. </li></ul>
  18. 18. Architecture-Centric MDSD (2/2) <ul><li>Since some implementation code remains in traditional textual languages, robust patterns need to be used to be able to maintain handcrafted code and generated code independently. </li></ul><ul><ul><li>The preferred solution is to keep handcrafted code in a separate set of classes. </li></ul></ul><ul><ul><li>However the pattern of injecting handcrafted snippets of code into tagged locations within generated code is a widely used pragmatic solution whenever there is no scope to refactor the existing code base. </li></ul></ul><ul><li>In practice one of the biggest weaknesses in enterprise applications is a lack of modularization. Architecture-centric MDSD is ideally suited to provide modularization constructs </li></ul><ul><ul><li>In component approaches interfaces are the focal point for all analysis and design activities. </li></ul></ul><ul><ul><li>Solutions are designed as collections of collaborating components . However, there are different abstract levels on which this component design may be considered. </li></ul></ul><ul><ul><li>The degree of achieved modularization depends on the degree of encapsulation achieved via component interfaces and on the number of dependencies between components . </li></ul></ul>
  19. 19. Relevance of Open Source Tooling <ul><li>Assessment from the organizers of the OOPSLA'02 workshop &quot;Generative Techniques in the Context of Model Driven Architecture” : </li></ul><ul><li>The era of expensive software development tools is long gone. The market already discards MDA tool-hype, and does not readily buy into MDA. On the other hand, domain-specific approaches and generator technology have a huge potential. The main problem is not one of tools - as some vendors would like people to think - but one of culture. Unless this is recognized, MDA will become the CASE of this decade. … </li></ul><ul><li>The only realistic way to gain widespread acceptance for the use of MDA-type approaches and generation tools is by addressing the related cultural issues, and by providing tools at a very low cost - so low that a CEO or CTO does not have to think twice. How about an open source-based project? While the tool vendors jockey for position and battle amongst themselves, an open source project may actually deliver results and become a de-facto MDA standard. </li></ul><ul><li>Stock take 2006 : </li></ul><ul><li>Within the sphere of influence of the Eclipse platform Ecore is developing into a widely used common denominator for interoperability between MDSD/MDA tools. </li></ul><ul><li>This is a very positive development, and it demonstrates that the Eclipse EMF Ecore implementation of MOF is quite usable. </li></ul>
  20. 20. Knowledge Transfer <ul><li>Agile Management </li></ul><ul><li>Monthly validation workshops with stakeholder and end users </li></ul><ul><li>Description of use cases at appropriate level of abstraction and granularity </li></ul><ul><li>Requirements prioritization based on use case scenarios </li></ul><ul><li>Project tracking based on use case scenarios </li></ul><ul><li>Component Based Development </li></ul><ul><li>Fully externalized component interface specifications </li></ul><ul><li>Using components to modularize domain layer </li></ul><ul><li>Techniques to eliminate circular dependencies </li></ul><ul><li>Tool assisted architecture quality management </li></ul><ul><li>UML Modeling </li></ul><ul><li>UML Use case modeling </li></ul><ul><li>UML modeling of component designs with required and provided interfaces </li></ul><ul><li>Modularization of UML models </li></ul><ul><li>Using UML to model work product definitions and dependencies between work products </li></ul><ul><li>Model Driven Code Generation </li></ul><ul><li>UML Model-Driven code generation with Eclipse EMF </li></ul><ul><li>Use of protected areas to implement non-destructive regeneration that preserves handcrafted code </li></ul><ul><li>Use of custom code templates to automate generation of navigational code </li></ul><ul><li>Architecture Quality Management </li></ul><ul><li>Definition of formal software architecture models </li></ul><ul><li>Definition of formal architectural constraints </li></ul><ul><li>Definition of formal subsystem models </li></ul><ul><li>Using Sotograph to automatically check code base for architecture violations </li></ul>