- Enterprise Business Architecture
- Project Business Architecture
- Value Chain (supporting activities, primary activities)
- Business Context
Open Group Business Architecture Views: (strategy, organization, process)
- People
- Process
- Function
- Business Information
- Usability
- Performance
The business architecture view is derived from business scenarios, where each scenario is defined by describing the problem, environment, objective, human actors, system actors,a nd roles and responsibilities.
Business architecture focuses on aligning business strategy with IT implementation, by:
- Identifying goals and strategy
- Identifying organizational structures and governance and their impact on strategy
- Applying the strategy across the entire enterprise
- Aligning with external entities
- Identifying quantifiable outcomes tomeasure the strategy
- Identifying the processes, rules, and information necessary to support the outcomes
- Managing and synchronizing the process model, business rules model, and information models
EterpriseBusiness Architecture
- Formalizing b usiness strategy into goals and outcomes
- Identifying common enterprise business semantics- Identifying common enterprise processes and rules
- Identifying enterprise opportunities and value
- Developing strategic roadmaps
- Providing alignment and innovation
- Considering competitive forces and competitive strategies
- Aligning with external organizations (the virtual enterprise)
Project Business Architecture
- Context diagrams
- Process models
- Information models
- Integration of enterprise semantics into project models
- Integration of enterprise semantics, common processes, and services into the project design
Areas of Business Motivation Model (BRG & OMG)
- The Ends and Means of businessplans
- The Influencers
Means->**->Ends
Mission->operationalize->Vision
Strategy->support->Goal
Tactic->achieve->Objective
Policy
Rule
Create Business Process Models
- Use Cases (Multiple Scenarios)
- Documents (information passed between steps in a process)
Organizing Services
- Keep the models focused on the business
- by business competencies and responsibilities
- along subject matter domains
The Service Inventory
- Enterprise Business Processes
- Business Services
- Domain Services
- Utility Services
- Foundation Services
Three levels of interoperability maturity
1. Project-specific interoperability
2. Business domain-specific interoperability
3. Business domain-independent interoperability
Service Context and Common Semantics
- Core Information Modeling (Objects, Attributes, Instances)
- Defining Types
- Identifiers and Uniqueness Constraints
- Specializations
- Derived Attributes
Structuring Information Models
- split into clusters of closely related objects (package)
- Documents can be thought of as hierarchical data structures with a main part and several, often nested, repeating parts.
Best Practices
- Using Abstraction to Avoid "SOA Stovepipes"
- Reuse Standards to Avoid Reinventing the Wheel (using enterprise semantics, using business-domain semantics)
- Develop Information Models Based on Use Cases
Designing Service Interfaces
Aspects of a service
- Interface (Service Operations, Common Business Semantic)
- Implementation ( Internal Functionality, Internal Data)
Service Characteristics
- Granularity
- Scope
- Visibility (range of users that are allowed to see the existence of a service)
- Interaction Styles (how information is passed into and out of the service, also called MEP) (Parameter Passing, Document Passing, Data Passing (data access), Request/Reply, Event, Mixed, )
Design Guidelines
- Isolating Responsibilities
- Understanding Overall Context
- Identifying Granularity
- Stateless Interfaces (Execution State vs. Invocation State)
- Exceptions (application exceptions, system exceptions)
- Designing Documents
Interface Design
Describing the business model can start with either the business process scenario or the information model (or both).
*Process-(or behavior-) centered aproach is more goal-oriented, providing a better link to the business requirements and processes.
Formal Versus Informal Specifications
- Informal specifications that are meant to communicate to a nontechnical audience
- formal specifications for complete and procise
Solution Model
- Refines the business concepts (processes, activities, entities, and documents) into SOA technology concepts of services, interfaces, operations, documents, and information)
The basic process is to work through each of the detailed business scenarios and evaluate every activity in the scenario as being implemented by servcie.
Three possible options:
- Define it as a manual task
- Assign it to a service operation. This is done either by creating a new service for it, or assigning it to an existing service
- Defer it as an internal task of another service. This often respresents a lower-level service that is part of the composition of the business service
Service Definition Diagrams
- Operations
- Documents
- Data Types
- Exceptions
- Associations
Basic Service Architecture (3 layers)
1. Service Interface Layer (Invocation, Syntactic validation, Data Transformation, Response)
2. Service Busness Layer (Semantic validation, Business Logic)
3. Resource Access Layer (Data Transformation, Resource Access)
Implementing the Interface Layer
- Implement the service contract
- Support interactios with the business layer responsible for the execution of the service functionality
- Perform syntactic data validation
Implementing the Business Layer
- Semantic validation of incoming parameters
- Sequence calls to other business logic, data access logic, other services or existing enterprise applications
- Conditional logic and business rule implementation
Service Composition
- Orchestration (Executable Business Process / Process Flow Focused)
- Choreography (Messaging and Rules / Conversational State Focused)
Hierarchical and Conversational Composition
- "Black Box" Composite Service
- Conversational Composite Service (Mediator)
Conductor-Based and Peer-to-Peer Composition
Service Component Architecture Composition
- Specifies how to create components, combine them, and expose the component assembly as a service
Event-Based Composition
Orchestration Engine-Based Composition
service Composition and Transactions
- The requirements of the Two-Phase Commit (2PC) conflict with the loosely coupled nature services
- An alternative to 2PC, supported by the majority of BPM engines, is compensation - invocation of business logic that can be called in case of a failure.
Enterprise Service Bus - Unified Infrastructure for Enterprise Soutions
ESB imnplementation
- Stand-alone ESB
- ESB as a service container
- ESB as a framework
Designing and Using Integration in SOA Solutions
*Treat integration as a specialized type of service - an integration service
*An additional element (business component) is introduced to the overall business service implementation
*Business components are not only building blocks for the business service but also a layer of abstractions for integration access.
Additional layers for Integration:
- Enterprise Resources and Operational Systems (existing systems)
- Integration Access (access to an existing application's functionality)
- Business components (deployable units of software that provide the (integration) functionality required by the business services
Integration Access Implementations
- Enterprise maturity in the EAI/integration space (existing middleware (messaging infrastructure) can be levferaged)
- Composition of the existing application portfolio (use packaged applications' Web Services)
- Business service implementation platform (e.g. J2EE server prepackage adapters (JCA/J2C)
- Integrated application implementation (Web Service wrappers)
- Type of integration(e.g. JDBC)
Data Mapping in Integration
- Implementing data mapping as part of the integration access implementation
- Implementing data mapping as part of the message delivery
Security Support for Integration
- Accommodate heterogeneity (i.e., multiple application platforms)
- Provide security management and identity propagation/management across multiple security domains (internal, external, and business unit silo)
- Support multiple security credentials that can identify subjects (and optionally, their authorization credentials (kerberos, SAML, etc))
- Support multiple transport protocols (HTTPS, JMS, MQ)
- Provide a mechanism for maintaining the "thread of identity" across the integration services invocations
Implementation of security support for integration
- Propagating the user identity as a part of the invocation of integration services
- Converting the user identity into a form required by a specific legacy application
Transactional Support in Integration (ACID)
- Atomic
- Consistent
- Isolated
- Durable
Dealing with Large Messages - Message Storage Area
Data Virtualization and Enterprise Data Bus
The additional layer - data virtualization - provides access to the enterprise data contained in either enterprise applications or their subordinated databasees. Business components are composed only of the components that implement service functionality based on existing application functionality, and data that is accessible through the Enterprise Data Bus.
Approaches to EDB implementation:
- Specialized server (e.g. IBM Information Server)
- Providing support for both direct database access and integration, and distributed data caching (e.g. IBM's Object Grid)
Posts
No comments:
Post a Comment