Definition of Business Analysis

June Sung Park, Business Analysis, Korea Software Technology Association, 2017.

British Computer Society defines Business Analysis as investigating business systems, identifying options for improving business systems and bridging the needs of the business with the use of IT. (https://www2.bcs.org/certifications/ba/)

International Institute of Business Analysis (IIBA) defines Business Analyst as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions (often including IT) that enable the organization to achieve its goals. (https://www.iiba.org/babok-guide.aspx)

SFIA (Skills Framework for the Information Age) defines Business Analsyis at competency level 5 to be to take responsibility for investigative work to determine business requirements and specify effective business processes, through improvements in information systems, information management, practices, procedures, and organization change; apply and monitor the use of modeling and analysis tools, methods and standards, giving special consideration to business perspectives; collaborate with stakeholders at all levels, in the conduct of investigations for strategy studies, business requirements specifications and feasibility studies; and prepare business cases which define potential benefits, options for achieving these benefits through development of new or changed processes, and associated business risks. (https://www.sfia-online.org/en/sfia-6/skills/business-change/business-change-management/business-analysis)

The following book, written in Korean, provides an easy guide to business analysis for executives and managers: June Sung Park, Business Analysis, Korea Software Technology Association, 2017. (http://www.kosta.or.kr/sub8/sub_board-no_view?id=1133)

Business analysis patterns are identied below which represent generally recommendable strategies and engineering practices for business analysis.

Business Analysts' Roles and Competencies

Figure 1. Core Competencies of BA at Capgemini

Business analysts (BAs)' roles are critically important in all enterprises, but more so in software companies which may develop and sell packaged enterprise applications or enterprise SaaS, or provide professional IT or CSB services.  People playing BA roles in software product or SaaS companies are usually titled Product Managers (PMs), while those in enterprises in general and professional IT or CSB service companies are most often titled BA.  BA and PM are used interchangeably in this article.

Domain & Engineering Expertise:   BAs' core role is to design a business model for a particular company or an industry sector (or called vertical) that will, often dramatically, improve business performance.  Designing a business model inevitably requires designing business concepts and business processes in an integrated manner.  Take the e-commerce of Amazon for example.   When Amazon reinvented the book retail business as ebusiness, it introduced the concept of product catalog portal, cart, checkout, e-payment, real-time shipment tracking, recommendation based on buying history, etc.  These are all new concepts from the viewpoint of conventional book stores.  The business processes behind customers' searching for books, selecting books based on rich information including other buyers' opinions, storing interested ones in a cart, checking out books in the cart to order, fulfilling an order, etc. are intimately related to the business concepts invented.  BAs invent new business concepts and related new business processes with deep knowledge and extensive experiences in a particular business domain (e.g., online book retail).

Therefore, domain knowledge is the most important competency for BAs.  Business semantic modeling using entity-relationship modeling or UML class diagramming is an essential competency of BAs.  Business process modeling, analysis and reengineering is another essential competency.  Metadata management (MDM) and business process management (BPM) are thus basic disciplines for BAs.

Capgemini has one of the best BA methods and training programs.  Figure 1 shows that Capgimini regards domain expertise, MDM and BPM as core competencies of BA.  Figure 2 shows the learning map for BA in Capgemini in 2009.  BAs are trained in: Capgemini's standard BA methodology called Structured Expert Method for BA (SEMBA), consulting skills, software engineering in general, Capgemini's architecture methods, service-oriented architecture (SOA), Rational Unified Process (RUP) which is Capgemini's standard engagement process, requirement enigineering methods in RUP, project management methods, and business case analysis methods.

June Sung Park, Software Engineering in the Context of Business Systems, in I. Jacobson and H. Lawson (ed.) Software Engineering in the Systems Context, College Publications: London, 2015.

Business Requirements Specification:  BAs produce business requirements for software development projects.  Business requirements may include as-is and to-be business process models, as-is and to-be information models, business use cases (i.e., functionalities to be delivered by the application), business services (i.e., REST or SOAP web service APIs), and user experience (UX).  Identifying business services is important because it is imperative today to build enterprise applications in  service-oriented architecture (SOA) or microservice architecture (MSA).  The reader is referred to the Microservice page in this web site to learn about importance, benefits, analysis and design methods, implementation technologies, etc. related to SOA and MSA.

The following articles dicuss about the importance, activities and work products of business requirements analysis in enterprise applications development:  June Sung Park, Software Engineering in the Context of Business Systems, in I. Jacobson and H. Lawson (ed.) Software Engineering in the Systems Context, College Publications: London, 2015. (http://www.collegepublications.co.uk/systems/?00007);  June Sung Park, A New Revolutionary Paradigm of Software Development for Mainstream Business Operations, International Journal of Technology Management 20, 3/4, 2000.

In the first article published in 2015, the author investigates systematic interrelationships between software systems and the business system where they are used, and those between software engineering and the software business where it is performed.  He discusses how software engineering methods have evolved to align software systems with the business system better and faster, and to adapt to the changing environment of software businesses. 

In the second article published 15 years before the first paper, he discussed about model-based development (MBD) and component-based development (CBD) methods which were widely regarded as revolutionizing the software industry in 1990s.  He illustrated the concepts of MBD and CBD using a then market-leading CASE tool--Composer from Texas Instrument Software (later rebranded as COOL:Gen by Sterling Software).  The model-based development tools like Composer automatically generated 100% of executable code from business requirement models and the model-based procedural logic (specified using a tool-specific, declarative 4GL): See Figure 3.

As can be seen from these two papers, business-IT alignment through rigorous business requirements analysis and modeling has been core foundation of software engineering for enterprise applications since 1980s.

Hands-On Modeler:  All software development organizations pursue lean and agile development today to improve value, speed, quality and cost.  One of the most effective ways to make sofware development more lean and agile is to eliminate handoffs among team members by enriching the job scope of software professionals.  The best BA would be someone who, after inventing an innovative business model and determining business requirements, incrementally translates the business requirements into a detailed software requirements specification (impliciltly in her head or explicitly in a modeling tool), and then codes, tests, builds and deploys the increment all by herself in a cycle time of a few hours.

Eric Evans calls such a person a "hands-on modeler" in his book on Domain-Driven Design (DDD).  He said: "If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of model-driven design—that the model supports an effective implementation and abstracts key insights into the domain—is half-gone, and the resulting models will be impractical. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a model-driven design."

Business Model Design

Figure 4. Business Model Canvas

Business analysis may start with a business modeling especially when a new business model such as an IoT-enabled digital business is pursued in an enterprise.  Business modeling should start with the customer.  Figure 4 shows a business model canvas (http://www.businessmodelgeneration.com/canvas/bmc) that can be used to sketch a business model.  Designing a business model starts at the end of the business value chain (i.e, from the rightmost section in the business model canvas towards left). Start with determining the target customers and their profiles (or personas).   The customer journey map can be used to determine the customer's new experience created by the business model.  In the book e-tailing example, the online book store's business model is created following the story of the customer's experience journey from book search, selection, order, payment, shipping, post-purchase evaluation, etc. (A. Richardson, Using Customer Journey Maps to Improve Customer Experience, Harvard Business Review, Nov. 2000)

The next step in business model design is to determine the value propositions of the product or service that will be sold to the customer.  What are the pains that are felt by customers today using incumbent solutions?  Can we relieve those pains with the new product or service?  What are unexpected gains that can be created for the customer by the business model in question?  The business model must create a discriminant set of value propositions vis-a-vis incumbent and potential competitors.  Value proposition canvas can be used to that end. (http://www.businessmodelgeneration.com/canvas/vpc)

Once target customers, products or services, and value propositions are envisioned and validated, the next step is to design a business motivation model describing stakeholders, business drivers and goals; a business strategy model suggesting the courses of actions to be carried out and business capabilities and resources to be built; and a business architecture consisting of business processes, business objects, business services, etc.  A business architecture method in an enterprise architecture framework such as TOGAF 9.0 (http://www.opengroup.org/subjectareas/enterprise/togaf) can be used to describe the business architecture.  Figure 5 shows an example of business architecture presented in ArchiMate 3.0 notation. (http://pubs.opengroup.org/architecture/archimate3-doc/)  It is a business architecture of a public software training business.

Business Motivation Model:  Figure 5.A shows a business motivation model describing business drivers (e.g., the public software training business wants to address customers' complaints about courses not directly helpful for improving their job performance at work) and business goals (e.g., support developing and maintaining a personalized learning map for individual customers, and provide more hands-on learning components).  Business goals provide the basis for defining metrics (i.e., KPIs) to monitor the outcome of the new business model.

Business Strategy Model:  Figure 5.B shows a business strategy model that includes strategic initiatives (i.e., courses of actions) to be carried out, new business capabilities to be built, and new business resources to be acquired to achieve the business goals.  For example, learning maps for different jobs and levels in software fields will be prepared to help customers develop their own learning road maps.  An innovative business transformation such as digital transformation often requires a new set of business capabilities and resources that are totally missing in current operations.  For example, GE's Predix, an IoT platform, is a new resource that GE developed to build a new digital business that provides software and analytics services to customers.

Business Architecture Model:  Figure 5.C shows a business architecture of the public software training business.  It shows business processes, business roles and business objects.  It also shows how different processes contribute to business goals, and which business objects are used in different processes.

Business Service Model:  Finally, Figure 5.D shows business services to populate the service-oriented architecture (SOA) of the application.  Closely related business processes and objects are encapsulated into a discrete service.  For example, the Curriculum Development business service encapsulates the Develop Courses process with the Course subject area composed of Course Metadata, Course, Course Taxonomy, Learning Map, Curriculum Designer, Courseware and Unit Price business objects.  There are 4 business services identified from business modeling.  They are candidates for being implemented as independent microservices.  These microservices will interact with each other and with external systems only via their open APIs.  It is good that the 4 services are loosely coupled--viz., each seldom needs to access the data owned by the other microservices.

Business Requirements Specification

Business Process Model:  A complex enterprise application involves many actors performing activities using data and information, in response to various business events, following prescribed business policies and rules.   Advanced business management demands standardization of business processes across the enterprise, and global optimization of business processes across the entire value chain rather than local optimization by departments. (M. Hammer and S. Stanton, How Process Enterprise Really Work, Harvard Business Review, Nov.-Dec. 1999; J. Ross, P. Weill and D. Robertson, Enterprise Architecture as Strategy, Harvard Business Review Press, 2006.)   With advances in business process management (BPM) and service-oriented architecture (SOA) as a pair of cross-fertilizing disciplines, global companies have pursued dynamic process orchestration that enables in-flight process reengineering in response to fast changing market, technology and competition environments since mid 2000s. (IBM, Business Process Management Enabled by SOA, 2009;  http://www.redbooks.ibm.com/redpapers/pdfs/redp4495.pdf)

Understanding a current business process, analyzing its problems, and designing a fundamentally reengineered process are in many cases the main driver of radical improvement in business performance, especially when new technology paradigms (such as mobile, social, cloud, big data, IoT, AI, blockchain) are applied.

 Figure 6 shows business process models specified in BPMN (Business Process Model and Notation) for the public software training business.  The enterprise value chain (a.k.a. the level 0 process) shown in Figure 6.A contains 4 processes identified in business modeling (shown in Figure 5.C and 5.D).  The process modeling in this Business Requirements Modeling phase decomposes those processes identified in the Business Model Design phase into more detailed subprocesses and eventually into atomic tasks.  Figure 6.B show a decomposition of the Book Classes process.

Figures 6.A and 6.B are drawn using BizAgi Modeler which is free.  Camunda Modeler is another popular free process modeling tool.  Both BizAgi and Camunda provide BPMN engines that can automate BPMN 2.0 process models for (micro-)service orchestration and human workflows.  BizAgi is positioned as a commercial, low code development platform (LCDP), while Camunda is an open source project focusing mainly on the core engine--a unified model-execution engine that can interpret CMMN (Case Management Model and Notation), DMN (Decision Model and Notation) as well as BPMN.

Business Semantic Model:  Business objects identified in the design of business architecture are analyzed to identify classes, attributes (or properties) of classes, and semantic associations among classes.  Each class should represent a single concept which could be a single physical thing (e.g., Employee), a single abstract concept (e.g., Department) or a single event (e.g., Product Order).  This is reminiscent of the first principle, called Single Responsibility Principle, in Bob Martin's SOLID principles of class design (http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod).

Classes are mapped to tables (or relations) if a relational database is used to store information on business objects.  The normal form requirements for relations also boil down to defining each relational schema to represent a non-decomposable single concept.  So designing a business information model (also called business semantic model, semantic data model) in UML class diagram or ER diagram is decomposing business objects (higher-level abstraction) into non-decomposable atomic concepts represented by either classes or entity types, respectively.  Figure 6 shows the business semantic model for public software training.  It contains subject areas such as Course, Class, Customer and Subject Matter Expert corresponding to business objects in the business architecture (in Figures 5.C and 5.D)  Classes closely related in semantics to form a higher-level concept are grouped in a subject area.

Classes have a complex web of semantic associations which represent deep knowledge on the business domain and specific ways the business concepts are applied in the business processes.  For example, as shown in Figure 7, a Course is composed of LearningObjects in compliance with the LearningObject Metadata specified in the IEEE 1484.12.1 Standard.  A particular Job requires competency in a certain set of LearningObjects.  The latter associations will constitute the LearningMap for Customers.  Customers are enrolled in Classes, each of which teaches a specific Course.  A Class may be delivered over multiple days.  The Instructor may vary on different ClassDays of a single class, but should be a single person for an entire ClassDay.  An Instructor of a Course must be one of the SubjectMatterExperts qualified to teach the Course.

Process-Object Model Mapping:  The semantic data model captures all the business policies and operation rules.  Therefore, it is meaningless to define semantics of business objects without taking full consideration of to-be business processes, policies and rules.  Business semantics and business processes must be designed at the same time preferably by the same analysts because they are inseparably connected.  A subject area is often a candidate for the bounded context for which a ubiquitous language can be established.  Each bounded context is a candidate for a microservice.  The reader is referred to the following references for discussions on bounded context and microservice: Eric Evans, Domain-Driven Design, Addison-Wesley, 2003; http://domainlanguage.com/; Sam Newman, Building Microservices, O'Reily, 2015.

Figure 9. Affinity Matrix between Use Cases and Classes

Process to Use Case Transformation:

Tasks in the leaf level of the process decomposition hierarchy are mapped to use cases that should be developed in the application.  Figure 8 shows a set of use cases corresponding to leaf-level tasks in the business process models (a portion of which is shown in Figure 6.B). 

Use Case-Object Model Mapping:  Closely related use cases are grouped together in a package (or called a module).  If you construct an affinity matrix between the set of packages and the set of subject areas, you will often find noticeable correlations.  For example, the Develop Curriculum and Learning Maps package mainly use the Course subject area and most of the classes (except the Course class) in the Course subject area are used only by that package. 

Examining the affinity matrix capturing interactions between packages and subject areas, or in more details between use cases and classes is helpful in strengthening the unification of business processes and business objects into a coherent and optimal business model.  Through analyses of affinity matrices, you can find superfluous business objects not used in any business processes, or the lack of a business object required by a business process, or a business object never created or updated or read by any business process.  An analysis of an affinity matrix enforces two-dimensional thinking (rather than one-dimensionally thinking about just processes or just objects separately), which helps make the models from different perspectives consistent with each other, thereby making each model correct and complete.

Figure 9 shows an example of the affinity matrix between use cases and classes in which each cell denotes their interactions in terms of CRUD.  (Microsoft, Connected Health Framework Architecture and Design Blueprint: Part 2-Business Framework, 2009)  The figure demonstrates the result of a clustering analysis performed on the affinity matrix which permutes use cases (rows) and classes (columns) so that a group of use cases and classes that have a high degree of affinity are clustered as a block on the diagonal.  These clusters can be candidates for SOA services or microservices. (P. Jamshidi, et al., To Establish Enterprise Service Model from Enterprise Business Model, 2008 IEEE International Conference on Services Computing, IEEE Computer Society.)

Scenario-Object Model Mapping:  A use cases can be elaborated by writing use case scenarios, each of which document a step-by-step procedure of executing a single path of the use case.  Figure 10 shows the scenarios written for the Make a Course Schedule use case using a modeling tool called Visual Paradigm (where the use case logic is described in a structured manner using branching and loops instead of writing individual scenarios such as a base scenario, alternative scenarios and exception scenarios separately).  The sentence in each step of the scenario is constructed using the ubiquitous language defined in the class diagram and the use case diagram.  Actor names are used as subjects, and class names and attribute names are used as objects in the sentences.  By writing scenarios using class and attribute names as object nouns is essentially encapsulating scenario steps into the classes as their operations or methods.  A use case scenario written in this way makes it straight forward to allocate the operations required by the use case to appropriate classes.

Software Requirements Specification

Business analysis (or software requirements engineering) should go through two phases.  First, business requirements are determined in an implementation agnostic way.  Business process modeling, business semantic modeling, business use case identification, use case scenario writing we have discussed so far can all be done at the conceptual level without concerning how they will be technically implemented.  These artifacts, however, need to be transformed and elaborated into detailed specifications for implementation--such as executable-level process models, specification-level class diagrams (a.k.a., domain model), logical database design, system use cases, system-level use case scenarios, UI wireframes, and system-level sequence diagrams, etc.--given a choice of technologies such as programming languages, application frameworks, runtime platforms, DBMSs, infrastructure, etc.

Class Responsibility Assignment:  Recall that a business architecture led to process models, which led to use cases and scenarios. Allocating use case scenario steps, i.e., operations, to classes (called use case realization or class responsibility assignment) can be aided by several methods, such as the affinity matrix analysis discussed above, CRC (Class-Responsibility-Collaboration) cards, and UML interaction diagrams including sequence diagram and communication diagram.

Object Design:  Once classes get allocated operations, it is said to be at the specification level, while it was at the conceptual level when it had only attributes specified as in Figure 6.  The specification-level classes can now be implemented as object-oriented code. Specification-level class diagrams and interaction diagrams together describe a domain model as defined in the Domain-Driven Design (DDD).

Conceptual-level class diagrams contain mostly entity classes that are made persistent in a database.  Object design patterns (E. Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1994; Martin Fowler, Patterns of Enterprise Application Architecture, 2002; Eric Evans, Domain Driven Design, 2003) can be applied to improve comprehensibility and reusability of class design and resultant object-oriented code.  Applying object design patterns will add various types of design-level classes such as factory class, command class, mediator class, observable class, strategy class, adaptor class, proxy class, just to name a few.  Figure 11 shows the domain model after assigning operations to classes to realize the Make a Course Schedule use case.

Figure 12 shows a sequence diagram for the Make a Course Schedule use case specified based on the domain model in Figure 11.  Classes mentioned in the use case scenario in Figure 10 appear as lifelines in the sequence diagram in Figure 12.  Messages written with horizontal arrows in the sequence diagram are method calls. Class responsibility assignment corresponds to figuring out methods required to be invoked on the classes to execute all the steps of the use case scenario. 

Recall that a business architecture led to process models, which led to use cases and scenarios, which in turn were realized by classes, which will finally get translated in a particular programming language.  This chain of transformations from one specification to the next brings high-level abstract ideas expressed in business models all the way down to executable code in a non-additive and non-loss manner.  An integrated modeling tool such as Visual Paradigm is helpful in ensuring the round-trip traceability from business models to code and vice versa. Some UML modeling tools such as Visual Paradigm has a code generation capability to automatically generate the source code from a class diagram in a chosen programming language such as Java, C#, etc.  However, you lose flexibility and control as you depend more on automatic transformations and round trip engineering capabilities of modeling tools.  You can still save a lot of efforts using automatic transformations though.  You have the tool automatically generate a transformed specification and modify them as you need (for example, to use a particular framework or library not supported by the code generator). 

Semantic to Logical Data Model Transformation:  The conceptual-level class diagram can be transformed to a relational database schema using a mapping algorithm that can be found in database textbooks such as R. Elmasri and S. Navathe, Fundamentals of Database Systems (2015).  This algorithm is reflected on object-relational structural patterns in Martin Fowler, Patterns of Enterprise Application Architecture (2002).  The algorithm basically maps each class to a single table.  A class association is mapped to a separate table if the association is many-to-many, or to a foreign key if it is one-to-many, aggregation, composition or qualified association.  Mapping the IS-A association (i.e., superclass-subclass association or generalization) is different depending on whether the classification is disjoint or overlapping and whether it is complete or incomplete.  Categorization requires a particular mapping.  BAs must master this algorithm because correctness of relational database design is critically important for enterprise applications.  Incorrect design will induce data corruption over time, which can cause enormous costs to the company.

Many UML modeling tools and ER digramming tools automatically translate a class diagram or an ER diagram to SQL DDL scripts that create tables and constraints.  Some modeling tools such as Visual Paradigm can generate an ORM code for Hibernate XML or JPA (Java Persistence API).  Again, you may want to override automatically generated table schemas, for example, to apply a different mapping option than the one applied by the tool.

The business semantic model is the basis for database and data warehouse design regardless of the implementation technology chosen.   Even if NoSQL data store is chosen to store business data, key value pairs, documents or column families are defined statically or dynamically based on the business semantic model.  For business intelligence (BI), too, multidimensional cubes are defined based on the business semantic model, regardless of whether multidimensional OLAP or relational OLAP is used for implementing the data warehouse or data mart.  If relational OLAP is used, a snowflake schema is derived from the business semantic model and materialized using a relational database.

Database design should include defining semantic constraints to maintain data integrity.  Business policies and rules can be enforced in several different ways.  One way is to code them in appplications using such patterns as the specification pattern suggested in domain-driven design.  Another is to use a business rule management system (BRMS).  A third is to use database assertions and triggers.

The agile business analysis process takes three phases:

(1) The upfront business requirements analysis, technical architecture drafting, and release planning that is conducted before the start of development sprints.  Here for requirement analysis, I recommend business process modeling using BPMN 2.0, business object modeling using UML 2.0 class diagrams, and a list of business use cases.  If you have done business modeling for the digital business you are developing, then you may use its output (such as customer journey maps and business architectures expressed in TOGAF ArchiMate notation) as input to the business process model and business object model.

(2) The software requirements analysis, architecture design, and sprint planning at the beginning of each sprint in the Scrum process.  Here you select a subset of business use cases to implement during the sprint.  In doing so, I recommend writing use case scenarios for the use cases, determining use case slices as the product backlog items, and conducting the planning poker to estimate efforts needed to implement each backlog item.

(3) Just-in-time, just enough software requirements analysis, evolutionary architecture design, and extreme programming (XP) that are conducted every day throughout the sprint. Here requirements analysis may produce on the as-needed basis the following artifacts: UI wireframes design based on use case scenarios,  the domain model (including specification-level class diagrams and sequence diagrams), database design based on the business object model, SOA and API design based on the domain model,  service orchestration or choreography design based on business process models, test scenarios based on use case scenarios.  Using these requirement specifications and test scenarios, developers should perform test-first programming, refactoring based on object design principles and patterns, continuous integration (CI), and continuous deployment (CD).

Business Analysis Metamodel

As has been discussed, various work products such as process models, semantic models, use cases, scenarios, domain models (specification-level class diagrams and interaction diagrams), logical database design, UI design are created first at the conceptual level and then at the specification or system level.  Each of these work products has a number of well-defined elements, and those elements are interrelated with each other inside each model and across different models.  Understanding the intra-model and inter-model interrelatedness is the key to understanding the essence of modeling in software engineering.  These interrelationships are defined in a engineering metamodel.

Business Requirements Metamodel:  Figure 13 shows the metamodel for models designed as business requirements (i.e., at the conceptual level).  Actors (or lanes) in BPMN process models should match those in UML use case diagrams.  Process tasks at the leaf level of process hierarchy should be mapped to use cases.  Input and output data of process tasks should be captured as classes and attributes in the semantic model.  And so forth ...  Again, it is inevitable to use an integrated modeling tool to maintain this complex web of dependencies correctly and consistently all the time.

Software Requirements Metamodel:  Now, Figure 14 shows the metamodel of software requirement models at the specification or system level.  Conceptual-level BPMN models are elaborated into executable-level BPMN models taking into consideration implementation technologies such as transaction management, messaging mechanism, etc.  The executable-level BPMN model can be run on a BPMN engine enabling process orchestration.  The executable-level BPMN model can be designed for an event-driven architecture, in which case it is implemented for process choreography based on a publish-subscribe messaging mechanism.

SOA services designed by encapulating classes and use cases are implemented as REST or SOAP web services.  These APIs should match the method calls required by executable processes.  Specification-level classes are designed by allocating use case scenario steps as operations to entity classes, and adding design-level classes following object design patterns.  CRC cards and sequence diagrams can help completing this class responsibility assignment.  Class interfaces should collectively match the service contracts designed for SOA services.  UI wireframes can be designed for each scenario step where the user interacts with the application.

Object-relational mapping (ORM) can be used to map classes to database tables and support database transactions.  There are debates, however, in the software community about pros and cons of using ORMs instead of SQL.  ORM frameworks like Hybernate can save efforts by eliminating SQL coding (especially when transactions need to be processed on multiple DBMSs from different vendors).  There are some drawbacks as well: performance problems when used for large databases with low-latency constraints, generating superfluous queries by default (unless tuned to avoid them), and inability to handle complex queries such as relational division queries and Group By/Having queries.  It is desirable for BAs and developers to get sufficiently trained in relational DBMSs and SQL so that they use ORMs selectively for convenience, not because they feel unconfident in writing SQL.

Comments

Took me time to read all the comments, but I really enjoyed the article. It proved to be Very helpful to me and I am sure to all the commenters here! It’s always nice when you can not only be informed