The document describes a BSAP (Business Systems Architecture Process) model for assessing the viability of complex business visions by developing accurate and complete models of the business structure, roles, and technical architecture to understand costs and returns for all roles in the ecosystem. It provides examples of reference scenarios, use cases, role definitions, and business modeling approaches used in the BSAP analysis.

1. BSAP ModelingBusiness Systems Architecture Process Al Lee

2. 2 BSAP Purpose A process designed to facilitate understanding of complex business models Complex Business Model= Dependent and Interdependent Heterogeneous Business and Heterogeneous Technical structures dependent on a dominant revenue or funding stream Heterogeneous Business Structure Attributes Multiple Roles required to fulfill new transaction value New Roles in Business Ecosystem Monetization of value unclear Revenue distribution unclear Heterogeneous Technical Structure Attributes Complex adaptive and reactive systems supporting the business Multi-domains Large scale effects Goal: Assess Viability of Vision

3. 3 Viability of Vision Viability Drivers Clarity of Vision Business Model ReturnonInvestment for ALL Roles Technical Model Architectural model to indicate context of Investment Quality of Models Accuracy Focus on Depth Contain sufficient detail to begin formal assessment to realize vision for Role or Actor Completeness Focus on Breath All Roles and Actors identified to fulfill value proposition Poor Clarity and Quality = High Risk

4. 4 Accuracy & Completeness Completeness = Breath Accuracy = Depth Role2 Role1 Role3 BSAP Focus Business Processes Business Processes Business Processes HL Functional Architecture HL Functional Architecture HL Functional Architecture Detailed Requirements Detailed Requirements Detailed Requirements Detailed Technical Specifications Detailed Technical Specifications Detailed Technical Specifications Product Focus Detailed Design Detailed Design Detailed Design Coding/Testing Coding/Testing Coding/Testing Implementation Implementation Implementation Ecosystem may be complete but Role1 functions may be too abstract to determine viability.

5. 5 BSAP Outcome Role Actor Business Structure Role Actor Business Integrity Technical Integrity Technical Structure Business Architecture Value Reciprocity Business Application Architecture Security Architecture Value Protection Value Functions Systems Architecture Infrastructure & Communications Value Support Understand the Cost of Value

6. 6 Primary Questions What is the Value proposition? Identifying the Product/Service A product is a set of Functions Who does the value accrue to? Identifying the beneficiaries Identifying the reasons for buying Who is the guarantor of the value proposition? Identifying who is the Producer of Value Owns the cost of creating and delivering value How is the value proposition likely to be monetized? Modeling the business structure for revenue/funding Understanding the competitive alternatives for the solution Designing in a Vacuum is Dangerous

9. Ecosystem Dependent Characterization

10. Test for efficacy: Role Rationalization

11. Functional ArchitectureAdheres toKey Business Principles Using an intuitive Notation Common SenseSemantics Intermediary Producer Consumer Business Archetype Rapid Virtual Business Model Prototyping

12. 8 Reference Scenario: Autonomics and Pervasive services Use Case Set Actors: Mobile Device Network Infrastructure Customer Infrastructure Clients 3 Use Case Sets Roles: Users, Device Manufacturers, Network Owners, Network Operators How Functions are Distributed Determines Complexity

13. 9 Key Business Principles User Specifier Buyer Revenue/Funding streams must be persistent Create, Sustain, Protect Functions must be sponsored Revenue or Funding from above Offering continuous value = Sustainability A product represents the set of all use cases Could be a widget, service or combination The Specifier decides the value Represents interests of all Buyer chooses best method of financing Value that is compensated must have a guarantor Liability is always limited Assets are protected based on risk assessment Audit Trails, Security An entity can only control what they own, pay for or have permission Major implications in Functional Architecture

14. 10 Role Glossary Outsourcer Discrete Role Profit & Loss Accountability Goal: Revenue Increase Sales New Value Propositions Bundling Existing Value Propositions Improve Brand: Enterprise/Product Reduce Customer Acquisition Costs Embedded Role A Department within Discrete Role Goal: Reduce Operating Costs Improve Quality Improve Performance Outsourcer Role (a type of Discrete Role) Can Provide Functions for Less Cost Has Scaling Advantages Consumer of Outsourcer is an Embedded Role Embedded Role Retains Primary Liability Enterprise Role (a type of Discrete Role) A Role that is a composite of Discrete Roles E.g. Cellular Carrier = HNBO, FNBO, NO, Store, ASP, Content Aggregator, etc Not documented as part of the Reference Meta Model Consumer Discrete Role Embedded Role

15. 11 Identify all Roles necessary for Scenario value instantiation End Consumer Role: Source of Revenue or Funding Existing Supporting Roles: Focus on Making Money or Saving Money New Roles: Focus on Customer Acquisition Costs and COGS Develop High Level Functional Architecture Set of Actors for end to end functions Identify Discrete versus Embedded Roles Discrete Role is a P&L Embedded Role is a department within Discrete Role Develop Relationships Reference Meta Model(A Business Entity Ontology) Distribute Actor Functions across Roles Apply Risk Mitigation as appropriate (security architectural implications) Assess cost implications to Discrete Roles (investments) Build Revenue/Funding Models Build Composite Entities (Enterprises) Volume and Pricing Assumptions (pricing elasticity) Test ROI implications on Discrete Roles (viability/sustainability) BSAP Modeling Move Towards Realizing the Vision Role Rationalization

16. 12 Business Model Business Risks Role Profile Name Description of Discrete Functions Role Relationships Consumers for Role: Revenue Streams Producers for Role: Embedded Roles and Vendors Interdependencies: Partners/Alliances Key Sensitivities Business Key assumptions and dependencies New relationships articulated if applicable Technology Key assumptions and dependencies New technical prerequisites Key Caveat: Dependency on New Role in Ecosystem Implementing New Technology

17. 13 The Unified Business Model v2.0 Notation Convention: All money flows from top down. Dotted lines represent new opportunities for analysis

18. 14 Meta Broker Modelinge.g. Use Case within Scenario Broker Producer Definition of Broker Intermediary: Many to Many Consumer Relationships Producer Relationships Other Intermediary Relationships Function Matches Consumer to Producers Referral of but not the Guarantor of value Compensation Transaction Fee based Business Model Dependent Consumer Pays Producer Pays Combination of Both Pays Consumer Need Broker Model

19. 15 Meta Broker Modelinge.g. Deconstructing the Use Case Consumer needs assessment Deconstruct Outcome for Scenario Declare Consumer Market Segment Define parameters: Goal, Constraints, etc Needs fulfilment assessment Fulfilment alternatives (use cases) Consumer discovery of broker(s) Methods Broker acquisition of Consumers Broker/Consumer Interaction/Protocol Broker/Producer Interaction Protocol Needs matching Contract terms Consumer : Producer Agreement Price Broker fees User authentication Payment Media Broker Functional Architecture Consumer dependency

20. 16 Motorola BSAP Real Results Through Structured Common Sense Dedicated to improving Business IQ Quality Timeliness Systems Cohesiveness Customer Satisfaction Al Lee Principal ALEE LLC alson.lee@gmail.com Cell: +1 847.219.4163

21. 17 Autonomic System Elements Objectn Object3 Object2 Object1 Agentd Agentc Agentb Agenta Configuration, Personalization, Registration State Data Acquisition Controls Manager Context Manager Policy Manager Provisioning Elements Operating Elements

22. 18 Semantic Update A physical device is a container for embedded actors that serve one or more higher level Entities. An Entity can be a Role or an Actor The physical device is under the control of a Entity A Role may require multiple physical devices to work together to achieve a goal (therefore multiple logical actors) There may be multiple logical devices within a physical device Each logical device will have some actors which are different A physical device can also be called an actor but only at the highest level of abstraction: a physical actor A Logical Actor is comprised of software. An Actor can represent a set of other Actors. The lowest level Actor has no embedded Actors. A Client is a type of Actor instantiated on a device that interfaces with a person. This software contains a user interface through a UI or GUI. An Agent is a type of Actor who acts as a proxy for another Actor or a Role resident on the same or different physical device. An Agent does not have a user interface.