 Now, we will see how architecture work products are created using formal notation, argument. Now, we have case study, presentation highlighting the benefits of argument methodology in real-life projects. I invite Mr. Vinod Vinod Tanulgar, solution architect from Shell India, to take us to the presentation. In his 17 years in the energy business, Vinod has architected integrated solutions across the energy chain, across an emerging technologies. Vinod has a bachelor's degree in mechanical engineering and an MBA in information technology. Vinod is also took at 9.175. Vinod, cheers. Thank you. Am I audible? Yes. Thanks. At this presentation, it would be slightly different. It puts me very light to consume, very easy to understand. And for me, it would be very difficult to answer your questions. So, it is the simplest presentation. Thank you. We will have you once again and welcome to this session on architecture. So, I am working with Shell as a solution and second architect. And I have been passionate about architecture for a long, long time. My professional belief is that modeling is fundamental to architecture. An architect should speak in a such a language which is easy to understand, easy to communicate. And there are no multiple interpretation from what he delivers. So, as a true architect, I deliver in terms of matrices, catalogs and diagrams. So, in this presentation, you will predominantly find only diagrams. This session is about demonstrating how we have leveraged argument in Shell for a project. As a Shell employee, I need to show this cautionary note and the same wherever you make presentation in public. So, there are just two objectives of this presentation. One is to demonstrate how really we make a standard work. So, I can keep hearing how to make a pudding, but this is the presentation attempting to give a taste of pudding to you. The second objective of this presentation is to demonstrate what real life benefits we have derived from this argument. So, there are just two plain objectives. This is the table of content. We will start with the problem statement, the statement which has given us to adopt argument and what we deliver. Then we will see select views drawn based on argument technology. We will summarize this presentation by concluding the benefits that we have derived. We do want to also adopt that terminology in your projects and then the session on difficult questions and easy answers. This is the most cluttered slide of this path. This shows how an architect when he is promoted to a project is over than by information. Corporate presentations, excel sheets, word document, free shapes, each shape meaning different to different things and all the inputs are fragmented. So, the poor architect is actually lost into an information overload and he has to allow the essence from this clutter. So, when I was awarded in this people tracking project, I also faced this fragmented and an ocean of information. But I said to business analyst, hey, don't give me the standard information template. Let us build the requirement together and let me architect the solution together. So, I saved the time of business analyst and the program manager by telling them, don't give, don't spend your efforts in creating a standard template kind of thing. And the first thing is to define a problem statement. Whatever we have the problem, we can still define it two lines. Take any problem, any big problem, enterprise level, segment level or solution level. It can be expected to take countries problem or universal problem, we can still define it in couple of sentences. So, we started with two sentences. The project was about people tracking. As an oil company, we need to track people where they are in the upstream, in the refinery. And whenever there is an emergency, we should be able to find out how many of the accounts are there. We should be able to communicate with them and we should be able to collaborate with them. So, we defined what is input tracking. Input tracking is a ability to know which zone of our studies. That is a simple problem statement. This was the first step. This is the first diagram I created. This we called as business requirement view. But in argument parlance, it calls into the category of motivation view. What you see here are just three notations. The requirement notations at the bottom. All these requirements, they influence the outcome of the project. So, out of the multiple calls that I had with business users and business analysts, I captured all the requirements 1, 2, 3, 4. And finally, we wanted to have the outcome of all this project was to have an input tracking solution. Simple diagram. It may so happen that these requirements are conflicting, overlapping, redundant, or at times not practical. But we made it a point to capture all the requirements. This diagram is not about logical correctness. This diagram is about contextual significance. When business users see this diagram, they say, yes, this is what you want. So, this diagram is getting validation from the business users. So, this was the first diagram we created. It is very easy to create any architect that easily create this diagram. And we can say on 2000 words of that narrative we write on business requirements. We can replace 2000 words with this single one diagram. We were not able to read because it is cluttered. But then this is the functional decomposition diagram. This is the most important diagram. It models the functional requirement. It models the solution capability. What we did from all the calls and communication that we received. We first modeled the five high-level solution capabilities, application capabilities. The notations used here are application capability and aggregation. Once you are able to model five to six high-levels application capability, then you can break down into sub-functions, sub-capabilities. And if there is a need, you can further have a whole granular requirement. So, in two three levels, you are able to model the entire application capability. This is the most important. This is where an architect has to play a role of consensus management or conflict management. Once you are able to decide the application functionality, it is as good as deciding the project scope. This will take the maximum time. Architects maximum time, functional decomposition diagram, any solution architect, any segment architect, any enterprise architect, working at state level, country level or universal level. If we put all our requirements in this, then that is almost like releasing the requirement. And then we are ready to architect the solution. The third diagram is related again for business users. It is a simple process flow, a simple workflow. How the solution will be utilized? Business users will like this, because something or the other figures the usage of solution. And then some activities take place in a sequence. This is basically modeling the behavior of solution. Very simple diagram. The fourth diagram that we created was use case. This use case diagram you will find mentioned in the photograph literature also. I have drawn it with argument rotation. What you find is a system with boundary. Within the system we have ordered the most important functionalities, the primary functionalities. And around the system you have roles and actors who will access that. Even though this appears to be very simple, it is very powerful, because from here you can identify which user should be given access to which functionality. The architect, the mismanagement architect will like this diagram because based on this you can categorize which user is company employee, contract employee or third employee, how solution is accessed, company device, private device, public network or company internet. So this use case diagram again very important. Now this diagram we created for the data architect. Because ultimately there is some data architect associated with the project and he brings up the data piece. So the beauty of argument is, argument allows you to model information in all the three layers. In the technology layer, argument models information in the form of artifacts, machine language, difficult to understand human beings, unscrupable. But the same artifacts are modeled as data objects in application layer, blue layer. In the form of data objects it is easy to slice, dice, roll up, print out. And the data objects then they realize the business object. Business object means something which is easily readable in the form of dashboards, in the form of canned reports. So argument models same piece of information but as an artifact in technology layer, as a data object in application layer and as business object in business layer. So this diagram will be important for the data architect or data modeler who is there in the project. So this is the application functionality and component mapping. We talk about taking architectural decisions. One of the important role of an architect is to take architectural decisions. This view can help to take the architectural decision. In the view we have seen there is main functionality and sub-functionality in model and on the right side we have mapped the candidate solution component. In this diagram we move from architectural building blocks to solution building blocks. This diagram helps you to take a decision whether to go for market standard, whether to go for literacy or exploit the existing ideal infrastructure or parts. So this application component is having mapped. So this is the diagram based on which an architect takes the decision. This is another important view which the integration architect would be interested in. You can see all the application components have been modeled here and within the application component the key functionality has been nested in functionalities. This diagram shows how the application components they use each other or they support each other. It also shows how together all the application components they orchestrate to deliver the complete solution capability. Very important diagram. So this is the last diagram based on the argument. Now as a share employee when I am onboarding a project I work on requirements of certain geography. Then what happens? Requirements from another job is also coming. So there is always a need to have a global view and then have a global view of solution. This kind of view will help you to find out what different geographies, what different operating units, what utilities they are deriving from the same solution. So when I was working for Bruna and when I was working for Nigeria, when I was working for say Canada, different requirements for it and when I modeled all those requirements we came to a conclusion that essentially they want the same solution but the end utility is different. Some geographies want emergency response, some geographies want worker efficiency, some geographies want people onboarding. But essentially they all can be met with the help of same people type of solution. So this was an important benefit that derived. Now this is directly from the horse's mouth, the program manager and the business analyst. They have appreciated this work. They see a value in this kind of work. It has saved a lot of time and they wanted this to be adopted in other projects also. This is the last and concluding slide. These are the benefits that we derived by adopting argument meteorologies. The first and foremost, when you are drowning in the sea of information, argument can help you dive over it. Whenever you get fragmented information, you can model the requirements and then come clean out of it. Adopting argument, you can identify and engage the stakeholders, create views which are pertinent to them. For example, views for the data architect, views for the integration architect, views for the business users. You can model both structure as well as behavior of the solution. Normally, modeling of behavior of solution is not possible in U.M.L. human type of modeling. But here, the argument allows you to model the behavior of the solution. Another important benefit is, you work on architectural building blocks and also you can transform into solution building blocks. And finally, adopting argument will help you take decision, help you in marriage and activities. As an architect, you are always balancing the business requirement and attitude solution. You can come to the consensus what the solution should be based on the architectural principles and based upon the stakeholder consensus. That's all.