Value-Obsessed Lean Framework

The Value-Obsessed Lean Framework (VOLF) is a lean process to develop complex enterprise applications to create innovative values for the customers.  VOLF has been developed and is continually evolved by Dr. June Sung Park in collaboration with several colleagues.

VOLF integrates design thinking, enterprise architecture, lean startup, business analysis, domain-driven design, extreme programming, agile development, and DevOps practices into a seamless process of developing applications for the digital transformation of an enterprise.  Contents of VOLF have been taught to thousands of software professionals and graduate students.

VOLF is being adopted, fully or partially, by an increasing number of companies in the software and other industries, including Yullin Technology,  Mind One, ezCaretech, Younglimwon, FORCS, CyberLogitec, Mirero, SERi, Hanwha Life, Samsung SDS, Korea Institute for Defense Analyses, Moornmo, Korean Standards Association, Fursys, Naviworks, S-Core, CAS, Hyundai Autron, Hyundai Motor Company, Citibank Korea, DoctorSoft, Hyundai MOBIS, SK Hynix, VTW, Metanet DT, Sinsiway, F1security, TongYang Systems, Hyundai AutoEver, Sinsiway, 2e Consulting, Mobigen, UXN, Miracom, SmartPort, etc.

In the video given below from https://youtu.be/tDBY_ZCilwM, I explained in Korean the "SW300" program that teaches state-of-the-art software engineering for digital transformations based on VOLF.  VOLF-based software boot camp programs such as the SW300 provide hands-on exercises and capstone projects as well as lectures and case studies, covering the end-to-end life cycle of a full-stack application, which is model-driven, service-oriented, deployed as containers on aPaaS on IaaS.

No software engineering practices (viz., neither Scrum nor DevOps, in fact, none of popular practices) are universally effective.  They must be carefully selected for and tailored to specific companies and specific projects.  No single software engineering practice or prescriptive process is sufficient by itself for developing software that meets the business goals.  A case in point:  Eric Ries, author of The Lean Startup, confessed, "When it came time to pivot and abandon that original strategy, almost all of my work--thousands of lines of code--was thrown out.  I felt betrayed.  I was a devotee of the latest in software development methods (known collectively as agile development), which promised to help drive waste out of product development.  However, despite that, I had committed the biggest waste of all: building a product that our customers refused to use.  That was really depressing." Essence kernel and language have recently been adopted as an official Object Management Group standard for creating and enacting software engineering methods (https://www.omg.org/spec/Essence/).  Dr. June Sung Park was Chair of the Revision TF for Essence 1.1.  Using Essence, one can compare practices, assess potential gaps, make needed practice improvements, and assemble select practices into a coherent method to benefit the project team.  In addition, by providing practical checklists, as opposed to conceptual discussions, the Essence-powered practice becomes something the team uses on a daily basis. This is a fundamental difference from traditional approaches, which tend to overemphasize method description as opposed to method use. Figure 1 (adopted from June Sung Park, Essentialization of Software Engineering Methods, SEMAT Essence Conference, Seoul, May 2017) shows that software product management (SPM) based on design thinking and lean startup, agile modeling, XP, DevOps and Scrum can be combined to address critical business and engineering concerns in a software product company.  Refer to: June Sung Park, Paul E. McMahon, and Barry Myburgh, Scrum Powered by Essence, ACM SIGSOFT Software Engineering Note 41, 1, January 2016 (https://dl.acm.org/citation.cfm?id=2853088);  June Sung Park, Jin Young Jang and Eun Jung Lee, Theoretical and Empirical Studies on Essence-Based Adaptive Software Engineering, Information Technology and Management, January 2017 (http://rdcu.be/onJu).  VOLF can be used with Essence to optimize the selection and assembly of practices for a specific software development organization.

VOLF Principles

VOLF suggests a menu of practices to choose from for a specific situation.  But whatever practices are chosen from VOLF by a specific company or project, VOLF insists on the following principles:

Lean Principle: Waste of work-in-process (WIP) such as analysis models, design models, test cases, etc. must be minimized.  That is, no artifacts should be created that will not materialize as code.  VOLF views a software engineering process as a pull system where you start a new work only when there is a customer demand for it.  This implies just-in-time, just-enough delivery of work.  For example, a detailed requirement analysis is performed incrementally--just enough, just in time for the features to be released to customers in each iteration of development.  Lean principle favors the model refactoring suggested in the domain-driven design (E. Evans, Domain-Driven Design, 2003),  Rather than making elaborate up-front design decisions, BAs and developers take code through a continuous series of small, discrete design changes, each leaving existing functionality unchanged while making the domain model deeper, suppler or easier to understand.

Metamodel-Based Traceability:  The lean principle requires that every work product in software engineering must be traceable from and to each other along an association path.  There should be no work products dangling alone.  To that end, VOLF provides a rigorous metamodel that defines the rules of association between the work products.

For example, a block of code is traced up to a class in the domain model, and to use case scenario steps of a use case; the use case is in turn traced up to a task in the process model; the task is in turn traced up to a new business capability required in the business architecture model.  On a different dimension, a class in the domain model is traced up to a conceptual business object in the semantic model which defines the ubiquitous language for the business domain in question.  The class in the domain model is mapped to (traced down to) a table (or a document, column family, key value store if NoSQL is used).  Columns of the table are mapped to fields on UI wireframes.  On a still different dimension, methods in the class are mapped to REST API operations of a microservice.  This microservice is traced up to a bounded context in the domain model, and so forth ...

Value Obsessed:  Every piece of work should contribute to creating values to customers.  Some work products are ruthlessly abandoned if not validated valuable to customers.  But such failures make contributions, too, if the team learns something from them.  In fact, the whole VOLF process is to fail fast, fail cheap, and fail often.  The team discovers and learns valuable features for the product through failures.  Value obsession is based on customer obsession, the first of 14 leadership principles of Amazon (J. Rossman, The Amazon Way, Clyde Hill Publishing, 2016; J. Rossman, The Amazon Way on IoT, Clyde Hill Publishing, 2016)  As Jeff Bezos, CEO of Amazon, said, "Start with the customer and work backwards, seeking continuously to earn and keep the customer's trust."

Business-Driven:  Practices are adopted from VOLF to improve the business performance of the adopting company.  There must be a strategic business reason for adopting a particular practice.  The Software Business section in this web site recommends good patterns of software business management.  Companies that find themselves practicing anti-patterns hurting their business performance should consider adopting some parts of VOLF that could remedy those anti-patterns.

VOLF Adoption Strategy

Different companies have adopted different parts of VOLF depending on their current maturity levels of software engineering and urgent needs to improve their business performance.  There are inevitable prerequisites for successfully adopting each practice.  Companies should carefully examine their readiness for adopting each practice.  The best approach is to set up a long-range adoption road map understanding that a certain set of practices are a prerequisite for another practice.  For example, business analysis using requirement engineering disciplines is a prerequisite for test-driven development.  Test-driven development is a prerequisite for build automation and continuous integration, which are in turn prerequisites for agile development.  Agile development and microservice architecture are prerequisites for DevOps, and so forth ...

Strangler:  Adopting advanced practices recommended in VOLF may bring political and cultural shocks to some people and organization units in the adopting company.  Typically senior employees accustomed to old ways of developing software or to anti-patterns of software business management become Résistance unless they are willing to unlearn old paradigms and relearn new paradigms.  The strangler pattern (https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler) of gradually replacing specific pieces of functionality in the legacy product or system with new applications developed using VOLF practices is a less disruptive approach to adopting VOLF in brownfield engineering.

Innovation Sandbox:  Applying the concept of "innovation sandbox" (https://www.strategy-business.com/article/The-Serious-Business-of-Sandboxes?gko=5feac) is also a less disruptive approach when developing a brand new product from scratch using VOLF practices (viz., in greenfield engineering).

Think Big, Act Small:  Try to make a series of small successes as you adopt advanced software engineering practices recommended in VOLF.  Set up a small cross-functional team including a product manager, several developers and customers.  Train the team thoroughly on a few practices that the company decided to adopt from VOLF.   Let the team develop a small application using newly adopted practices.  Monitor the team performance and productivity, the product quality in terms of its values to customers, maintainability and reusability, and most importantly the ROI generated by the application.  Institutionalize continuous improvement of engineering practices.  Once the initial team is fully confident in their competency in the adopted practices, roll the practices out to more teams with the initial team members serving as mentors for the new adopters.

VOLF Lifecycle

Design Thinking Loop

Design Model Prototyping:  As shown in Figure 2, VOLF starts with empathizing with customers following the design thinking approach.   It tries to identify value propositions, i.e., pain relievers and gain creators, for customers that should be delivered from the new solution.   After generating solution ideas, it designs the business model and high-level business requirements for the application.  The design models are reviewed with the customer to ensure that they produce innovative values for the customer.  BAs learn new insights on customer problems and value propositions through that customer validation test of design models.  They repeat this design thinking loop until a desirable, feasible and viable design is achieved.  The looping cycle had better be short as Time Brown recommends: Have a prototype (design models in case of VOLF) ready by the end of the first week or even the first day (Tim Brown, Change by Design, HarperBusiness, 2009; https://www.ideou.com/pages/design-thinking)

Business Requirements Metamodel

The work products produced in the design thinking process describe business requirements agnostic to implementation technologies.  Business requirements models include business motivation model, business strategy model, business architecture model, and high-level requirements models for the application.  The first three outputs are designed using ArchiMate 3.0 notation based on TOGAF enterprise architecture framework.  The high-level requirements models include business process models, business semantic models, business use cases, business service models, interaction models, and UI wireframes.  The process model is described in BPMN 2.0 notation and the other models in UML 2.0 notation.  The business semantic model is described using UML class diagram.  The interaction model shows, using UML communication or sequence diagram, how classes interact among one another at runtime to realize use cases.

Business Architecture to Business Requirements Transformation:  Figure 3 shows the metamodel for business requirements models.  It shows semantic associations among the elements in the business requirements models.  For example, business processes identified in the business architecture model and presented in ArchiMate notation is each described in more details as process models expressed in BPMN notation.  Such consistency and traceability across different levels of abstraction guarantee that business models are perfectly aligned with the IT solution.

The reader is referred to the Business Analysis section in this web site to learn engineering principles that make all the models at different levels of abstraction and from different views completely consistent with each other.  Among the high-level requirements models shown in Figure 3, use cases are mapped from process tasks.  Use case scenario steps where the user interacts with the application map to UI wireframes. Classes take responsibilities to process use case scenario steps and collaborate with other classes to realize each use case.  Those collaborations are shown in the interaction diagram.  SOA services encapsulate use cases and classes that have a high degree of affinity.  The database schema is transformed from the class diagram using object-relational mapping (ORM) patterns.

Lean Startup Loop

Build-Measure-Learn Cycle:  Once the business model and high-level business requirements are validated enough, an initial product backlog and a release plan are produced.  Given the backlog, an iterative lean startup process is started.   As shown in Figure 4, the lean startup process is also a fast feedback loop.  It goes through Build, Measure and Learn phases. (Eric Ries, The Lean Startup, Currency, 2011; http://theleanstartup.com/)

Agile Development:  The Build phase of the lean startup process employs an agile development process based on the Scum project management framework.  If a Sprint in the agile development process fails to produce a shippable product increment, the release plan is revised, and the lean startup process is restarted.

Innovation Accounting:  The lean startup process applies so called "innovation accounting" to measure the response of customers using actionable metrics.  If the response is negative, the lean startup process pivots back to the design thinking process to redefine the customer problems and product value propositions, and revise the business model and high-level business requirements.  If the response is positive, it perseveres with the current product backlog and proceeds to the next Sprint cycle.

Agile Development Loop

Figure 5 shows the workflow for the Build phase of the lean startup loop.  The Build phase employs the agile development process based on the Scrum project management framework.

Business Requirements to Software Requirements Transformation:  Business requirements models are designed just enough to clearly communicate with customers about the business model and the application to be developed.  These models evolve continuously as business analysts (BAs) and customers learn more through experiments.  The subsequent agile development will elaborate the technology-agnostic business requirements models into technology-dependent detailed software requirements models, and implement the models using specific programming languages, frameworks, platforms, middleware and infrastructure.  As models are detailed, implemented and released for customer feedback, business requirements models will be continually updated to incorporate learning from customer feedback.  Nothing is static or frozen in software development and maintenance.  However, it is important to maintain consistency and traceability across all models even if the models are always susceptible to changes.  Integrated modeling tools such as Visual Paradigm help maintaining the model consistency.

Just-In-Time Analysis:  An agile development cycle (i.e., a build phase of the lean startup loop) starts with updating the product backlog through a requirement analysis which incorporates customer feedback in the previous lean startup cycle.  After the update of the product backlog to ensure that user stories in the backlog are seriously desirable for customers, a Sprint Planning is conducted.  In the sprint planning, developers estimate efforts required for developing each user story--one by one in the priority order--using such a practice as the Planning Poker.  If developers cannot reach a consensus on the effort estimation of a user story, that means the requirement specification models supporting the user story are not clear and complete.  In that case, the sprint planning is stopped and the team goes back to requirement analysis on the ambiguous user stories.  Detailed requirements modeling is done just in time and just enough for the features to be developed in the next sprint.

XP-Based DevOps:  Once a Sprint Backlog is selected and a Task Board is set up for the current sprint, user stories are coded, tested and released using model-driven design, extreme programming and DevOps practices.  Figure 6 shows the workflow of model-driven design, extreme programming and DevOps process executed for each selected user story, provided that the continuous deployment releases one feature at a time.  A team may batch a number of completed user stories over a time duration (like a day) and then build and perform an integration test periodically (like daily) with the batch.  The CI (continuous integration) cycle and the CD (continuous deployment) cycle may be different (like daily build and weekly release).  The lean principle favors a "small batch size" to minimize waste of WIPs. (https://queue.acm.org/detail.cfm?id=2945077)  Releasing one feature at a time means a batch size of one.

Software Requirements Metamodel

Figure 7 shows the metamodel of software requirements models.  These models are designed incrementally just in time and just enough for each sprint.  They keep evolving as sprints iterate and the team learns more and more about valuable features for the customers.

Metamodel-Based Inter-Model Consistency:  In Figure 7, the domain model specifies all the classes required for the application, their semantic associations and runtime dependencies.  The domain model is designed using UML class diagram, communication diagram and sequence diagram.  The database schema for relational and NoSQL databases are generated from the class diagram.  Relation schemas in the 5th normal form can be automatically generated as an ER diagram, SQL DDL script or ORM code (e.g., JPA annotations implemented by Hibernate) using modeling tools such as Visual Paradigm.  Recall that any automatically generated code should at least be inspected, and more often regarded as just an aid to help you jump start your own coding saving the typing time.

Use cases are captured from business process models and UX models. Atomic tasks at the leaf level of process models are mapped to use cases.  Ad hoc user tasks identified from UX analyses are also mapped to use cases.  Test cases can be generated from analyzing use case scenarios.  UI wireframes can be designed for each scenario step that requires an interaction between the user and the application.  UI wireframes can be used to run a slide show demo to get quick feedback from customers.

Use cases are realized by classes.  Use case scenario steps are mapped to class operations.  CRC cards (Class Responsibility Collaboration cards) can be used to allocate operations to classes.  The domain model is continuously enhanced through model refactoring as the team learns more deeply about the business domain.  Object design patterns are applied to improve comprehensibility and reusability of classes.  (Eric Gamma, et al., Design Patterns, Addison-Wesley, 1994;  https://www.oodesign.com/; Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002; https://martinfowler.com/eaaCatalog/)

Service-Oriented Architecture:  Bounded contexts are identified in the domain model. (Eric Evans, Domain-Driven Design, Addison-Wesley, 2003; http://domainlanguage.com/; Sam Newman, Building Microservices, O'Reily, 2015)  Each bounded context with a well-defined ubiquitous language is implemented as a microservice.  REST or SOAP web service interfaces are generated for microservices.  Business process models in BPMN 2.0 can be elaborated into an executable level and translated into executable scripts to run on a BPMN or BPEL engine.  See the Microservice section in this web site to learn about service-oriented architecture (SOA) and microservice architecture (MSA) principles, design patterns and design practices.

The following Youtube playlists present Dr. Park's talk explaining (in Korean) how object-oriented software is designed through class responsibility assignment (i.e., use case realization), domain modeling, and refactoring based on object design principles and patterns.