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.

WSSR and LDAP

Configure WebSphere Service Registry (WSSR) with LDAP

http://www.ibm.com/developerworks/websphere/library/techarticles/1304_bharade/1304_bharade.html?cmp=dwtrial&cpb=dw&ct=dwads&cr=nws0413&ccy=in

WesService (SOAP) and JMS MQ

http://www.ibm.com/developerworks/webservices/library/ws-soapmqjms/

CICS and Web Service

http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfha4%2Fresources%2Furimap%2Fdfha4_attributes.htm

Agile/Scrum techniques for Big Project:

Scrum techniques:

If the project are big or other words if the huge number of User stories have been created; how do manage such big project through agile. Is agile is right way to adopt, is agile will be successful than any other model.

So many question and no confirm answer.

Let start with first step from agile and digging out some answers which might be helpful to make the decisions.

1. Agile means Epic-US-Task-Coding-testing-Features Ready.

2. Product Owner and SM working togther to get above things done with stakeholder and product manager.

3. Now questions started

• Can features will be ready without Testing - No it can not be
• Can testing be done without Coding - No it can not be
• Can Coding will be done without task creation - Might be (yes/No)
• Can task will be created without complete US - No it can not be, here i am saying complete US means, US details/COS and clear understanding of the US; if any US bring into the sprint without all these it will impact the sprint velocity, resources utilization and product owner effort as well. So these kind of US can not bring in any sprint.
• Can US will created without EPIC/requirement - No it can not be

So overview of the above details means US (Product Backlog) needs to be created, COS needs to defined and US should be completed (publsihed) ahead of the task creation.

My opinion All known US needs to be written and published before coding started.

This is something like Army needs to go for some operation before that planning and trial needs to be done. On the decision day it is just matter of time for the expert to execute the plan, take any big Army execution as an example.

So decision day start when you bring the development team into the game until than it is just planning with product owner, product manager and stakeholder.

This way organization can save time, money and more than that utilization of resources

4. Calculating the velocity will help along with resources capacity planning as well.
If team sprint velocity is "X" and resource capacity is "Y" after calculating resource capacity SM will get some number (velocity) which can be either "X" or "X+Z"; this new number can not be "X-A" since team can not be less than thier velocity.
This activity will help SM to project the rest of work as well.

5. Try to avoid creation of any additional  US based on the velocity.

6. Team should alwyas have at least 6 to 8 sprint (2 weeks sprint) work.

7. Every team member can shadow each other or back up should be ready within in a team to take over the sprint work.

8. Last but not least have 90%  to 95% US completed before decision day started.

9. try to create Small features and tied these features to pre releases.

10. Pre-releases date can not be move in any conditions

11. Add one product owner as Scrum says but keep many analyst which is equivalent to product owner (Proxy Product Owner) but they will work with Product Owner to create and validate US so team utilization.
This activity will help department and team for better utilization of resources and budget utilization as well.

Some do and don't while running such big projects.

Do
1. User stories needs to be maintain by Product Owner/Product Manager
2. Only Product owner can add or delete the US.
3. Scrum Master should talk to Product owner for any new US.
4. Every US must have tasks.
5. Expolaroty testing can be fit for agile development.
6. Product owner should signed off for every Sprint.
7. Every Epic/US should have some points (example poker points) assigned to it.
8. Changed any completed US COS with approval of Product Manager with additional Poker Points.
9. Define small points to any US, that can be done during in sprint.
10. Create couple of Sprints for UAT and Production planning.

Don't
1. During the Sprint trying to avoid take US.
2. Don't do any POC during the sprint.
3. COS and US details needs to be clear so team can understand very well.
4. Dont assigned big points to any US
next article: Agile and EA and other architecture

Enterprise Model and Agile Testing

AGILE Testing and Enterprise Model of Agile