Summary
That case study is meant to illustrate the Caminao EA workflow. It is based on Roger Sessions’ example (“A Comparison of the Top Four Enterprise-Architecture Methodologies“) about a chain of drug stores trying to combine the development of new IT systems with a M&A strategy. As many options have been conjured up errors would be mine and comments and amends welcome.
The legacy system consist of three programs: MAM/Store, which ran on a small computer at a drug store; MAM/Warehouse, which ran on a server in a regional warehouse; and MAM/Home, which ran on a large server at the home office. These programs communicated with files transferred through FTP between locations.
Now the company wants to expand through the purchase of three regional chains and the systems are hampering the future, e.g:
- MAM/Store required regional specializations. For example, different insurance plans needed to be supported in different regions, and these all required changes to the MAM/Store module.
- The regional warehouses that had been acquired through acquisition each had different ways of receiving orders from the retail stores and different procedures from ordering supplies from the wholesalers. Each of these differences required changes to the MAM/Warehouse module.
- The file-transfer approach to information sharing that had worked so well when MedAMore consisted of 30 drugstores, one regional warehouse, and one home office were turning out to be difficult to coordinate among 200 drugstores, four regional warehouses, two geographic offices, and one home office. Files were often delivered late, sometimes not at all, and occasionally multiple times. This made it difficult for the home office to access reliable, up-to-date financial information, especially in the areas of sales and inventory.
MedAMore systems overview as represented in the Caminao Ontological Kernel (CaKe_WIP).
The company clearly needs to revamp its systems but attempts have repeatedly failed on combined bottlenecks:
- Technical: over 1 million lines of code for each module, cross dependencies between functions.
- Organisational: the business side wanted to acquire two more regional chains, but IT was still struggling to bring the existing acquisitions online.
Redefining the problem along an enterprise architecture perspective, as opposed to traditional project management, was then considered.
Enterprise Stories & Architectures Capabilities
The inflection point between engineering and EA projects is the translation of business-vision statements into concepts that could be mapped to architecture capabilities; in that case:
- Extension of stores in at least 30 states, spread out over 8 geographic regions, by the year 2010. Accomplished mainly through acquisition of regional pharmacies.
- New regional systems to be assimilated within 120 days of finalization of purchase.
- Purchasing costs to be reduced by 10 percent by consolidating all regional purchasing into a central system.
- Consolidated reports for sales and inventory from all stores up to and including the previous day available from central office.
- Inventory on-hand reduced to no more than a five-day supply.
- Insurance companies invoiced by the end of the day on which the prescription was delivered to the patient.
- Patients will be able to transfer prescriptions from any MedAMore pharmacy to any other.
- Patients will be able to request prescription refills though a Web interface and receive e-mail notification of their availability for pick-up.
Whereas some objectives can be neatly associated to singled out capabilities, others will involve cross dependencies; in that case concepts can be introduced to refactor requirements until they can be anchored to primary capabilities.
As represented with the Caminao Ontological Kernel (CaKe_WIP):
Impact Analysis
Given that changes can be set at any level (enterprise, systems, or platforms), the objective is to identify dependencies and define work units in a way that will minimize disruptions to enterprise activities.
With regard to business and organizational dependencies:
- Reporting capabilities may affect the way business rules are implemented.
- Consolidation of purchasing systems will affect data architecture
- Capabilities for new stores and the integration of new regional systems will probably overlap
- Requirements regarding prescriptions will require additional data in patients records
Then, enterprise architects must take into account engineering dependencies cascading across layers, e.g: refills and prescriptions; purchasing systems and inventories, …
Finally, legacy dependencies may be the more challenging ones as they often combine functional and technical changes, e.g the changes affecting patients which will have to maintain the functional and technical continuity between current and future records as well as the interoperability of applications.
As far as enterprise architecture is concerned, the focus is to be put on governance of capabilities, engineering being under the responsibility of projects. On that account changes can be regrouped into three categories depending on the nature of their footprint on capabilities:
- Users stories: prescriptions transfer and refill
- Business logic: changes mainly affect business logic, e.g insurance plans needed to be supported in different regions, requiring changes to the MAM/Store module.
- Processes: changes also affect control and participants, e.g the integration of orders (from retail stores) and purchases (from wholesalers) require changes to the MAM/Warehouse module.
- Non functional: the footprint of change is set across processes, e.g file-transfer solutions are obsolete.
In order to mark the difference between architectures and representations, information architecture capabilities are given a special attention with entities stereotyped with regard to capabilities: locations (e.g warehouse), actors (e.g wholesaler), physical (e.g inventory) or symbolic (e.g order, drug reference) entities.
Store Module: Prescriptions & Invoices
With regard to prescriptions two main work units can be identified:
- New applications for transfer, refills, and e-mail notification, and corresponding patient web interface (SMa).
- New application for insurance plans and invoicing (SMb).
The integration of new regional systems and insurance plans are centered on the Store module with changes to prescription process control and communication capabilities to be carried out with the overall transformation of the network architecture.
Warehouse Module: Purchases & Inventory
The Warehouse module is to be comprehensively redesigned in order to support the consolidation of all regional purchasing into a central system and to ensure lean inventory management.
These specific objectives are to be achieved together with the broader and strategic one of integrating new regional systems within 120 days.
Home & Communications Module
The integration of new regional systems within 120 days is a strategic objective on both business and technical account. Beside a new middle-ware architecture, it is to condition the more specific objectives for purchases and inventories, reporting, and integration of new stores.
Time-frames
While EA transformations are best achieved on a continuous basis, they still must be set with regard to enterprise time-frames, e.g: strategic, tactical, and operational.
Operational (c): whatever can be observed and acted upon by adjusting resources without changes to the specification of artifacts (physical or logical) and the normal course of business:
- Reduction of inventory on-hand (assuming no changes in applications or organization).
Tactical (b): whatever can be observed and acted upon by adjusting artifacts, assets and organization without changes to business concepts and models:
- Extension of stores
- Consolidated reports for sales and inventory.
- Invoicing of insurance companies.
- Transfer of patients’ prescriptions between pharmacies.
- Web application for patients prescription refill.
Strategic (a): decisions regarding the definition of business objectives, assets and organization (e.g consolidation of purchasing):
- Integration of new regional systems.
- Consolidation of regional purchasing into a central system.
Even without explicit constraints, one should ensure that changes are not carried out across boundaries.
EA Workflows & Framework
To be of any use, EA workflows must be continuously tied with maps and territories as to maintain an up-to-date and consistent description of contexts and objectives (territories>maps), engineering (maps>maps), delivery (maps>territories), and deployment (territories>territories) of resources. Taking Invoicing for example:
- Mapping of business objectives and work unit inception.
- Development of self-contained components; entry to EA roundabout.
- Completing development while circling; exit from EA roundabout and delivery to operations.
- Configuration and deployment.
The shift of governance paradigm from phased development process to iterative EA workflow is to remove two basic obstacles:
- Conflicts between IT and business units are worked out through collaboration between managers, analysts, and architects.
- Scheduling conundrums are disentangled by defining time-boxes with regard to enterprise specific time-frames and introducing a level of indirection between delivery and deployment.
That tallies with the basic agile principles of shared ownership and continuous delivery, thus demonstrating the importance of scaled agile for EA workflows.
Annexe
A different case study has been developed with OWL and the Caminao Ontological Kernel
Further Reading
- EA Case study with Ontology
- EA in bOwls
- EA: Work Units & Workflows
- EA: Maps & Territories
- Thread: EA
- Enterprise Architectures & Separation of Concerns
- Where to Begin with EA
- Models Transformation & Agile Development
- Agile Architectures: Versatility meets Plasticity
- Agile Delivery & Dynamic Programming
- Abstraction Based Systems Engineering
- Caminao & EACOE
- EA & MDA
- Abstractions & Emerging Architectures