From StakeHolders to deployment… How to start this journey?

And it happened again … All together in a room… more than 20 people, supposedly those who “develop the product” so that “the rest of the development labs” could develop software in a more productive and “agile” way … Basically those who should have been developing the SBBs which were defined in the early stages of architecture design … From the “supreme leader” (of course guru of everything) to the developer, and of course “travelling through” the Scrum master who didn’t do another thing that talk about the Product Owner … and not precisely praising him. Everyone knew what they were doing, but in a totally egocentric way … without knowing the reason, nor the final result of what they were developing.

The best was what follows:

• Member X: “… Well, what you are saying that you need, I already did it long time ago
• Member Y: “really??, I have not seen it in Confluence, nor in JIRA, or any simple document explaining it … An email at least?? did you leave it in some GIT branch GIT to be able to keep an eye on it?”
• Member X: “Nooo , actually I have it at my local machine. 🙂 “
• Supreme Leader: ” !! ey team!! … if you see that what you are developing or testing, is something useful for the team, how is it that you have it in your local machine?.. and worst… how is it that you didn’t mention it to the team?”
• Member X: “Since no one has told me about the need of that piece of software, I realized that I needed it, I built it for “my testing project “and there it is … Now if someone wants it, just ask me “
• Member Z: ” jejejej Well, that functionality had already been developed by me and I told you … Don’t you remember that we talked about it on daily meeting?

No comments.

Taking into consideration that this is not a correct agile execution project and team nor there weren’t used properly the agile tools provided, this a real situation brainstorming of trying to apply new architecture approximation, (or not so new but “fashionable”), and focus in the state of the art of it.

But let’s go deep in our “EAMind business”; in the first post we talked about the ABBs and the SBBs; in the second one we introduced the concept of “Viewpoint modeling” using Archimate views… In this, we are going to mix the main BBs of an organization (people, which is the correct answer of the first post :)), how to apply a point of view for these ABBs associated with the project and their responsibilities!!! AHHH it’s sound like a RACI matrix!!!; No!!, we will use diagrams to describe the system and then trace all the artifacts of the originated architecture, so we’ll be able to find out why a project was originated, who were linked to it, and to know how each piece of the puzzle fits for each generated artifact

ISO 42010 in its meta-model, explains in a clear way how the “stakeholder” interact with an architecture and which are the relations that should be taken into account:

“Stakeholders’ Management” is explained in detail in TOGAF specification itself. This “Stakeholder management” must also be aligned or enriched with other standards and bodies of knowledge (if we have the opportunity) in order to improve each area based on our experience either in project management or in architecture discipline, or in architectural project management :); specifically, I am referring to area number 10 of the project management professional standard (PMP – PMI). Joining both “worlds” and frameworks, TOGAF and PMP, and focusing on what we intend to “exploit” in this entry post, i.e… How do I represent, within an enterprise architecture, the most intangible branch such as the relationships created in time to carry out a project, and in a next step later in time, be able later to exploit the result of the project itself? The first, like always, is to identify the points of view that we want to apply to solve the situation and above all, the “FOR WHOM” they would be directed to.For this we would have the following available, depending on the stakeholder, (think that we can always ADAPT them to our organization):

Stakeholder	Key Concerns	Class	Catalogs, Matrices and Diagrams
CxO (Corporate Functions); e.g., CEO, CFO, CIO, COO	The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business.	KEEP SATISFIED	Business Footprint diagram Goal/Objective/ Service diagram Organization Decomposition diagram
Program Management Office (Corporate Functions); e.g., Project Portfolio Managers	Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision-making.	KEEP SATISFIED	Requirements catalog Project Context diagram Benefits diagram Business Footprint diagram Application Communication diagram Functional Decomposition diagram
Procurement (Corporate Functions); e.g., Acquirers	Understanding what building blocks of the architecture can be bought, and what constraints (or rules) are relevant to the purchase. Acquirers will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) derived from the architecture, such as standards. The key concern is to make purchasing decisions that fit the architecture.	KEY PLAYERS	Technology Portfolio catalog Technology Standards catalog
Human Resources (HR) (Corporate Functions); e.g., HR Managers, Training & Development Managers	The roles and actors are required to support the architecture and changes to it. The key concern is managing people transitions.	KEEP INFORMED	Organization Decomposition diagram Organization/Actor catalog Location catalog Application and User Location diagram
Enterprise Security (Corporate Functions); e.g., Corporate Risk Management, Security Officers, IT Security Managers	Ensuring that the information, data, and systems of the organization are available to only those that have permission, and protecting the information, data, and systems from unauthorized tampering.	KEY PLAYERS	Product Lifecycle diagram Data Dissemination diagram Data Security diagram Actor/Role matrix Networked Computing Hardware diagram Communications Engineering diagram
QA/Standards Group (Corporate Functions); e.g., Data Owners, Process Owners, Technical Standards Bodies	Ensuring the consistent governance of the organization’s business, data, application, and technology assets.	KEY PLAYERS	Process/Event/ Control/Product catalog Contract/Measure catalog Application Portfolio catalog Interface catalog Technology Standards catalog Technology Portfolio catalog
Executive (End User Organization); e.g., Business Unit Directors, Business Unit CxOs, Business Unit Head of IT/Architecture	The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and architecture to advance the business.	KEEP SATISFIED	Business Footprint diagram Goal/Objective/ Service diagram Organization Decomposition diagram Process Flow diagram Application Communication diagram
Line Management (End User Organization); e.g., Senior Business Managers, Operations Regional Managers, IT Managers	Top-level functions and processes of the organization, and how the key applications support these processes.	KEY PLAYERS	Business Footprint diagram Organization Decomposition diagram Functional Decomposition diagram Process Flow diagram Application Communication diagram Application and User Location diagram
Business Domain Experts (End User Organization); e.g., Business Process Experts, Business/Process Analyst, Process Architect, Process Designer, Functional Managers, Business Analyst	Functional aspects of processes and supporting systems. This can cover the human actors involved in the system, the user processes involved in the system, the functions required to support the processes, and the information required to flow in support of the processes.	KEY PLAYERS	Business Interaction matrix Actor/Role matrix Business Service/ Information diagram Functional Decomposition diagram Product Lifecycle diagram Business Use-case diagram Application Use-case diagram Application Communication diagram Data Entity/Business Function matrix
IT Service Management (Systems Operations); e.g., Service Delivery Manager	Ensuring that IT services provided to the organization meet the service levels required by that organization to succeed in business.	KEEP INFORMED	Technology Standards catalog Technology Portfolio catalog Contract/Measure catalog Process/Application Realization diagram Enterprise Manageability diagram
IT Operations – Applications (System Operations); e.g., Application Architecture, System & Software Engineers	Development approach, software modularity and re-use, portability migration, and interoperability.	KEY PLAYERS	Process/Application Realization diagram Application/Data matrix Application Migration diagram Software Engineering diagram Platform decomposition Diagram Networked Computing/ Hardware diagram Software distribution Diagram
IT Operations – Infrastructure (System Operations); e.g., Infrastructure Architect, Wintel support, Mid-range support, Operational DBA, Service Desk	Location, modifiability, re-usability, and availability of all components of the system. Ensuring that the appropriate components are developed and deployed within the system in an optimal manner.	KEY PLAYERS	Platform Decomposition diagram Technology Standards catalog Technology Portfolio catalog Enterprise Manageability diagram Networked Computing/ Hardware diagram Processing diagram Environments and Locations diagram
IT Operations – Data/Voice Communications (System Operations); e.g., Network Management	Location, modifiability, re-usability, and availability of communications and networking services. Ensuring that the appropriate communications and networking services are developed and deployed within the system in an optimal manner.	KEY PLAYERS	Communications Engineering diagram
Executive (Project Organization); e.g., Sponsor, Program Manager	On-time, on-budget delivery of a change initiative that will realize expected benefits for the organization.	KEEP INFORMED	Requirements catalog Principles catalog Value Chain diagram Solution Concept diagram Functional Decomposition diagram Application and User Location diagram
Line Management (Project Organization); e.g., Project Manager	Operationally achieving on-time, on-budget delivery of a change initiative with an agreed scope.	KEEP INFORMED	Application Communication diagram Functional Decomposition diagram Environments and Locations diagram
Business Process/Functional Expert (Project Organization); e.g., Financials FICO Functional Consultant, HR Functional Consultant	Adding more detail to the functional requirements of a change initiative based on experience and interaction with business domain experts in the end-user organization.	KEY PLAYERS	Process Flow diagram Business Use-case diagram Business Service/Information diagram Functional Decomposition diagram Application Communication diagram
Product Specialist (Project Organization); e.g., Portal Product Specialist	Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution. In a packages and packaged services environment, product expertise can be used to identify product capabilities that can be readily leveraged and can provide guidance on strategies for product customization.	KEY PLAYERS	Software Engineering diagram Application/Data matrix
Technical Specialist (Project Organization); e.g., Application Architect	Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution.	KEY PLAYERS	Software Engineering diagram Platform Decomposition diagram Process/Application Realization diagram Application/Data matrix Application Migration diagram
Regulatory Bodies (Outside Services); e.g., Financial Regulator, Industry Regulator	Receipt of the information they need in order to regulate the client organization, and ensuring that their information requirements are properly satisfied. Interested in reporting processes, and the data and applications used to provide regulatory return information.	KEEP SATISFIED	Business Footprint diagram Application Communication diagram
Suppliers (Outside Services); e.g., Alliance Partners, Key Suppliers	Ensuring that their information exchange requirements are met in order that agreed service contracts with the client organizations can be fulfilled.	KEEP SATISFIED	Business Footprint diagram

Of course, we have to take into consideration the “motivation catalogue” we want to have with each stakeholder of the organization and the project (column “Class”) in order to conveniently manage the stakeholder expectations.

Basically we handle the following values:

And depending on this, we will know (or at least have a guide) how to act … what periodicity or insistence we have to have with each other and, above all, know how to communicate WHAT IS NECESSARY to each one of them and in an appropriate way and with the detailed grain that each one requires or demands

Now, if we link the recommended diagrams for the stakeholders management with the views of an architectural languages such as Archimate, and we focus on an IT project and software delivery, we could use different PoVs (Points of View) to define “the what” and “the how” is reached.
We’ll start by associating some views of the “Motivational” perspective and from there, we will go down “inventing” a need that is performed with a requirement which will be solved by offering a certain business value (in our case we should remember that our business is our own Architecture) that will be implemented with a software component and that will be deployed in a specific machine. All using the same LANGUAGE, elements and relationships … for a better and simple understanding of each of the artifacts that are “inside” each diagram you can go here.

What we want to do is a “cross cut” section in the architectural perspective including (or showing) that a special need that we detected in the organization, can be solved and reflected in our enterprise repository in such a way that we always will know what originated “what” and “by whom” if it’s needed, and logically the artifacts generated, its location, owner, etc…:

Linking an architecture framework like TOGAF with an architecture language like Archimate (2.1 version here):

Because we began this post by referencing the people who make up a project and its possible shortcomings, we will model those deficiencies and their possible derivative solution (remember that it is a merely illustrative example to make understand the idea and added value of diagrams) beginning with a Transversal Motivation perspective:

We first focus on the goals we want / we should achieve in our organization and therefore in our associated Enterprise Architecture (let’s not forget the words “Architecture” and “Enterprise” and what they include), for this, we use a standard Archimate PoV that is a “Stakeholder Viewpoint” focusing on the goal we want for our project, that is … “Improve the understanding of all the StakeHolder of the project”:

From there, and focusing on a composition of the main objective, we could “drill down” to another motivation PoV that could explain how and why project is originated… Let’s choose for example the Goal: “No ABB or SBB without information”. To achieve this goal, we can represent in architectural language how it could be done using a PoV that shows how that goal would be achieved by some requirement. “Requirement Realization” view point also from the motivation extension perspective:

Here, at the same time, we can identify and express the necessary requirements to achieve the objective and the business services that will perform those requirements. In this simple example, we have identified that we have to assign an “owner” with sufficient capacity and empowerment to govern the architecture repository (“Assign responsible with capabilities”) and also that each element of that repository has to be correctly identified and associated with an architecture building block so that it is not unlinked (“SBB Description and association”)

An issue that usually happens continuously when we are “engaged” in the IT world, is that each business service, are associated directly to an implementation software that resolves it. This is a big mistake. A business service is that, a service that solves a business need that has been identified in the company, either implemented by a final software system or simply with an action that has value. All of this is also part of the EA. For example, in this case, we have “simulated” a business service of responsible assignment, that could be resolved simply with an assignment and a task by the HR department of the organization, and another business service (which is the one we are going to explore here) that will be realized with an application software implementation. Let’s see how we could define the business process of this second one mentioned. We will use a “Business Process” PoV for this purpose:

In this moment, we have already reached the level of Business Architecture and we define the process at the functional level so that a business analyst can easily “understand” us … Additionally we include elements such as Interaction between roles, in such a way that we know who interacts in the architecture business process, putting boundaries in the responsibilities as well. If we go deeper in definition and to see who is who and which role are supporting this solution, we use an “Actor Cooperation viewpoint”.

In the previous “Business process view” , we observe two “Business Objects” in this layer … Remember that we are not talking about Software, here we only think about Business Objects and how we associate them into the process … In this case “ABB” and “SBB” … we reiterate that here our business is ” the architecture “and therefore our business objects are these 2 basic elements of cataloging (for simplifying the example).

Let’s recap: After identifying a lack of business and indicate that we must achieve some goals in the organization, we have defined how those goals could be achieved and realized through the definition of some linked requirements and a way that, those requirements are implemented (either with a software or without software). Just at this moment we are ready to “go deeper” to another perspective … The Information Perspective (Application and Data).

For this, we can identify another PoV that helps us to express the need we wanted to solve with a Software system … Let’s see that application service (“Update Content Repository”) already appears in the Business view … Let’s say that what we are “doing” is a link between Business and application domains by means of an Application Service in such a way that a business person is interested in the business process and not how it is going to be solved at the level of software artifact … This technique is very important to refine conversations with specific stakeholders and for this, to be able to respect and “measure” correctly the expectations and satisfaction degree of the stakeholder in particular … whether he is a CxO, an Architect or a DBA. Let’s see a simple example applying this PoV. To accomplish this:

Now in this perspective (The Information one) we have two domains in it … the one referring to the application (the previous diagram showed) and the one of Data. Realize that in previous application diagram we are referring to certain “Data Objects” (those that we have called “XXX” data) … But, How could we know what business concepts these data objects refer to? What is the meaning of your instances within the context of the organization and the project we are dealing with? For this, we could use another Archimate PoV and we picked for this example the “Information Structure Viewpoint”

If we go deeper into the data perspective, each of the “Data Objects” would be translated into a Data element and its corresponding diagram (if it applied obviously). For example, a Typical Entity / Relational diagram that reflects the detail of entities, attributes and relationships associated with the data model in question that would be generated in a development phase.

And at this point with the data objects, what would be the next step to reach the next domain? How could they be associated later with an infrastructure device? Can I infer the final implementation and deployment of those software elements and the final machines where they will reside? To accomplish this, we move towards the physical world from a software design perspective … Let’s think about giving a solution to the implementation of our previously designed artifacts, in such a way that we know how it is built at a technological platform level, which are the communication, their protocols,… we could reach the detail level we desire to show and to register … but I’ll just try simplify the solution for this post…

Let’s “define” that the final solution could be resolved by 2 application components; one of them obtains its information from a relational database and the other one from a documentary database. The application has been developed in Spring, for example, and both components are deployed in a Jboss Application Server … There is also a communication with the organization’s ERP system that, for risk and operational safety, is located in another physical location and, in this case, from there is where you get a file with the Stakeholder data that we need … This is a not very real (or optimal) solution at the Software level Architecture, but imagine this to show another PoV (“Infrastructure usage view”) of this perspective:

And with all of this all together, let’s ask us… Have we solved the original problem? Could we see what would be the Stakeholders linked to a software artifact? And therefore … could we indicate to a CIO that the deployed application uses an Oracle DB, whose version is about not to be supported by the manufacturer soon? Could the CIO be contacted with the architects who came up with the solution? And the architects with the development team?…
The answer to all these questions is YES …For example, for the first question, let’s remember the “Actor Cooperation View”, where we had the information of the stakeholders and collaboration of people, so we can search and contact specific person if we wish…

Some software tools can realized such a kind of searches. This is an example, so we can execute from all the artifacts of our design projects to get all the information that we want, and that we need, generating views according to the stakeholder needs. In this case “Who were the people in charge of build and deploy the architectural solution that was deployed in the machine X”:

From a machine where is deployed an application to the team who designed it and built that application…. and the best is that everything is placed in our Architecture Repository represented in such a way that, every time what is needed, is given to those who need it and in a visual way with a simple query or search, providing the information we want to extend and inform them because they are important in our organization.

Just to finish lets question ourselves some points: How many documentary repositories would we have had to access to “understand” the requirements? How many “office documents” or requests to people (if we are lucky and we know them into the organization) would we have had to ask for? And how many obsolete presentations (or worse, “forwards of mails” with 8 different responses within different colors or owner-acronyms about the same discussion of the solution would we have to read to get an answer? And surely more than one person in that emails would not even have to have said anything… How long would it take us? … And the best of all … Would we be able to give an answer on time? Would we be productive? How much money do organizations loose simply for a bad understanding of information and for not betting in solutions of serious architecture projects and continuing with “solution fixes” that the only thing they do is distort this important area of knowledge.

In this post we have “traveled” through the architectural perspectives and we have used architecture languages in detail to show that trip … We have seen an apex of what can be done using these techniques in a correct way … There are many standard PoV and extensions that can be used to adapt it to our needs. In future post entries we will complement this one with 2 perspective that we have not been able to address (throughout the entry). The “Implementation and Migration” perspective that exists since 2.1 specification and some of the new domains with new artifacts that have been incorporated into the specification in Archimate 3.0.1 revised and released recently… Physical and Strategic perspective… Let’s see how accomplish it…!! See you soon and enjoy EA !!