Enterprise Architecture Modeling

Enterprise Architecture Modeling

There are three existing high level architecture models that are aimed to various groups of people from executives, business users, architects, engineers, etc.

1.       Enterprise Contextual Model

2.       Conceptual Model

3.       Architecture Model

These models can be built using any architecture process models (TOGAF framework, Zachman framework, etc.). These models can be used throughout the life cycle of any project. These models will be artifacts during any architecture process.

1.       Contextual Model:

Enterprise Context Model (ECM) is divided into two viewpoints, current and future vision of the organization/business. It outlines the involved application/systems to build the new/enhance system.

Current ECM: It defines the current system state. It should outline the current system interaction (internal/ external), protocol, type of system, and name of the system.

Future ECM: It defines the future state of the system (new/enhanced). It will outline future system interaction (internal/external), protocol, type of system, name of the system, system sun-setting, new system added, security model, data repository.

2.       Conceptual Model:

a.       Business Process Diagram

b.      Detail Workflow

c.       Use Cases

Business Process Diagram:

v  A business process diagram (BPD) is a set of activities or collaborative services that helps to accomplish a specific organizational/business unit objective.

Use case:

v  An interaction between actors and the system to obtain a set of goals.

Use case Creation:

v  It is the next series of steps after BPD.

v  Use cases should map to the BPD tasks (a BPD task can have one or many UC).

v  Use cases will have more details (pre/post/triggered and action).

v  Use cases should have requirements details and not the “how to” details.

v  At least one use case diagram should be created.

Usages of BPD and Use cases:

If tasks are defined and the BPD is ready, the use cases can be completed based on the requirements.

v  Start developing logical and physical models of the proposed application.

v  A task created during BPD and the corresponding use case is also mapped to the logical model.  If a logical model becomes too complex, simplify the logical architecture model into the multiple logical models and map back to the assigned single use case.

v  If there are any changes in existing logical models, the corresponding physical model must be changed as well.

v  If LM does not exist, then the logical model needs to be created. This may be mapped to one of BPD tasks or use case but it is not mandatory.  It always helps for project traceability.

v  A logical model should not be complex; it should be readable and if needed split into more than one (does not need to be mapped to task/use cases).

v  Logical architecture model must map to physical architecture model.

Relations between a Business Process Diagram and Use Cases:

v  Creation of a business process diagram (BPD) is the first step before any modeling begins.

v  The BPD captures only business objectives; it is not the process workflow.

v  The BPD can have multiple business tasks and not the workflow.

v  Every task in the BPD is a representation of what the business does.

v  A business task can be consistent with workflow, but in BPD it is does not need to be displayed.

v  BPD should have a start and end.

Work Flow:

It is the routing of tasks or activities between people or a system.  It uses application-specific sequence of tasks defined with predefined rules, including automated or manual activities. It can integrate between workflow-specific systems and other external systems. It has the ability to analyze and report on content analysis. The process flow is a granular level detail in the flow and cannot provide multiple paths for the goal.

Business Process Flow (BPM):

A set of independent activities in any specific applications.

BPM vs Workflow difference:

BPM:	Workflow:
1. Characterizes a series of activities independent from specific applications.	1. This is granular level task/activities. Facilitates simple routing of tasks/ activities.
2. BPM is a superset of workflow	2. Workflow Automation Software uses application-specific sequencing of tasks established with predefined rules, including either automated or manual activities
3. It coordinate activities  and tasks among users	3. The ability to integrate between workflow-specific systems and other external systems is often limited, only allowing document and data retrieval
4. BPM connects different data/business processing systems enabling seamless data sharing and control from a single interface	4. This is specific to Application. Workflow Software is very basic in its ability to analyze and report on content analysis
5. Business processes, once defined, are modeled, automated, managed and optimized to be effective, cost efficient and achieve high operational performance	5. The process flow is fixed, meaning cannot adapt to or  provide for multiple possible paths to the same goal
6. It is used to capture, evaluate and analyze information from outside sources efficiently and effectively
7. BPM rules allow you to govern your organization or individual processes. It has ability to distinguish between execution rules and the actual flow of the process.

Similarity between BPM vs Workflow:

Organize the task and activities for reusability, automate core processes to eliminate bottlenecks, managing the task and activities in the form of flow/process, reduce redundancies and achieve operational efficiency.

4.       Architecture Model:

There are two major architecture models

a.       Logical Architecture (LA).

b.      Physical Architecture (PA).

Logical Architecture (LA):

Ø  Every logical model should classify into the enterprise layer, business layer, and distributed layer including security, presentation layer and database layer.

Ø  In case of data power/ESB or any other middleware interface, all the required API/framework must be displayed/incorporated very clearly in all logical architecture.

Ø  Any web service should have separate details, logical and physical models, including data translation and protocol translation for the consumer and the provider. These details should be depicted very clearly.

Ø  All the components defined in the logical model should have all details such as programming language, vendor solution name, product name, component or framework and database as well. 

Physical Architecture (PA):

Ø  Every physical model should have a corresponding logical model.

Ø  Every physical model should classify into the enterprise layer, business layer, and distributed layer including security if any exist, presentation layer and database layer.

Ø  Every physical model should have detailed information about the system/region/partition/os/os version/app server/web server/browser/database details.

Ø  All components in each and every physical model should have infrastructure details and NFR details.