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

Uses, Include and extends

uses, Include and extends:

uses
The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior.

Include and extends:

The correct way to indicate a "include" or "extend" relationship is with a dashed line. Now the difference between the two is the following. 

Suppose A includes B. This means that whenever somebody does A she will do B too. On the other hand, if A extends B, than whenever somebody does A, B has nothing to do with it. But if you do B, you might do A additionally during the course of B. You should specify a condition under which A actually extends B.

In this case both can be use as long as indicate in the condition of the extends version that this depends on the customer being new.
BTW "subclassing" is not the correct term, it is (again) generalization. Adding such a generalization implies that every new customer is a customer and can do whatever a regular customer can do.

Relationships are dependencies
The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. Use the terms 'base', 'included' and 'extending' to refer to the use case roles.

include:

Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one.

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. ( This is contrary to popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

In the best practice of one way dependency the base use case knows about (and refer to) the included use case, but the included use case shouldn't 'know' about the base use case. This is why included use cases can be: a) base uses case in their own right and b) shared by a number of base use cases.

extend:

Extend is used when a use case conditionally adds steps to another first class use case.

The extending use case is dependent on the base use case; it literally extends the behaviour described by the base use case. The base use case should be a fully functional use case in its own right ('include's included of course) without the extending use case's additional functionality.

Extending use cases can be used in several situations: a) The base use case represents the "must have" functionality of a project while the extending use case represents optional (should/could/want) behaviour. This is where the term optional is relevant - optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. b) In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). c) It can be used to extract out sub sequences of the base use case, especially when they represent 'exceptional' complex behaviour with its own alternative flows.

One important aspect to consider is that the extending use case can 'insert' behaviour in several places in the base use case's flow, not just in a single place as an included use case does. For this reason it is highly unlikely that an extending use case will be suitable to extend more than one base use case.

As to dependency, the extending use case is dependent on the base use case and is again a one way dependency, i.e. the base use case doesn't need any reference to the extending use case in the sequence. That doesn't mean you can't demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template; but the base use case must be able to work without the extending use case. 

1. Association is a relationship where all objects have their own lifecycle and there is no owner.
• example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
2. Aggregation is a specialized form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object.
• example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department, the teacher object will not be destroyed. We can think about it as a “has-a” relationship.
3. Composition is again specialized form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted.
• example of relationship between House and Rooms. House can contain multiple rooms - there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

Reference: 

1. https://www.geeksforgeeks.org/java/association-composition-aggregation-java/