Future of Cloud Service Delivery - End User Executable Service Catalog

AWS catalog service  represent the future of cloud service delivery model. AWS  catalog service help an enterprise to create a cloud  IT service catalog. The list may include a  simple services like  VM  availability to a  complex  N tier  business application.  The key thing is that all services can be deployed and provision by the authorize catalog user . Please see the image below to understand how cloud service catalog is created, provisioned and used.

Catalog has two type of user - admin and end user . The admin user are responsible for creating the services, apply governance, security and compliance policies  to each service and then publish it to service catalog.  Once the service is publish to catalog,  end users can  launch a specific service  on demand via self service mode . Service will be provisioned  on aws infrastructure and then end user can start using the service.

Catalog can be provision in terms of  multiple portfolio and services. Different portfolio can be created for different business units.

AWS service catalog is created using using aws existing services, mainly  - CloudFormation. CloudFormation is a AWS service which  can be used to create  an executable template .  A sample stack is given below

 A CloudFormation   template  represent aws resource like AMI, application stack  etc which need to be created a particular service. Template is basically a text file in json.  AWS  provide many built in template which can used for creating required resource. User can also  use a graphical tool provided by AWS ,  called template Designer in order to create custom templates.

Other AWS services like   CloudWatch, CoudTrail, S3 and CloudConfig can be used to provide a extensive monitoring view for admin user .

From Devop to Noop with serverless architecture

While most of the enterprise are struggling to really implement Devop in their enterprise , technology has already moved on  to Noop with server less architecture in the cloud. With AWS Lambda service,  you can write your code(currently limited to Node.js, Java , Python) as event invoked lambda function without worrying about any virtual server details . Please see the following figure to understand how AWS lambda works . 

once you have written  the code and done few simple configuration steps , the process of executing your code, which includes creating the AWS EC2 right size virtual server , installing the write image (Node.js, java, python),  security,  auto scaling on demand is taken care by Lambda. Developer does not have to worry about virtual server sizing, installing  right images,scalability, maintenance , monitoring etc. This is a  server less architecture from developers point of view. 

The trade off is that code written  as lambda function has to be short  . AWS Lambda runs all code in a container  and is highly suitable for micro services. 

Case management for knowledge work

Broadly speaking there are two approaches to managing collaborative work

Structured processes

Adhoc Process

A structured process is a process whose path can be clearly defined in advance. The order in which activities are to be performed is also  defined in advance  Process participants have very little discretion to change the  order or add a new activity on  their own discretion.  Structure process are suitable for certain kind of processes such as Order fulfillment, Expense approval etc... 

However, nature of our work is changing. Our work is becoming more and more knowledge driven. A knowledge worker (KW) perform his work based upon the information and his experience. A KW needs more discretion for performing his work. Adhoc processes are more suitable for such work. Adaptive case management is a discipline for implementing adhoc process. ACM automate every work which can be automated and leave rest of the work at the discretion the skill and knowledge of KW. A case has following components: -

§  Events

–      Event-driven

–      System and user-defined events

–      Case participant  can raise certain events on discretion

§  Content

–      Content/Document  repository integration content management system(CMIS)

§  Activities

–      Configurable at design time and runtime

–      BPMN, Human Tasks, Custom

–      Case participant  can  add/delete certain events on his discretion

–      Case participant  can   change the order in which activities are performed  certain   on his discretion

§  Data

–      Business Objects

–      External

§  Policies

–      Business Rules

§  Stakeholders

–     Case worker can add/remove stakeholder during case life-cycle

–     Case worker can change the permission give to a particular case worker

§  Milestones

–     Case management is a goal driven approach. A goal may have several milestones

–     When all the milestones are met, the goal of the case   is met and case is closed

–     Case worker can declare a milestone is met or not met at any during case lifecycle

–      

Most of the software vendors for BPMS (Business process management suite) are supporting case management. IBM, Oracle etc... provide support of case management. Case management is also called iProcess management and such system are called iBPMS

Some of the domain in which case management is very suitable are Patient Care, claim management in insurance etc..

2 ABC'S of SOA Service

One way to understand SOA is to understand two ABC’s of SOA. The first ABC of SOA, ABC1  is “Autonomous Business Capability”. ABC1  is what an organization does, irrespective of the fact how it perform it. Some examples of ABC1 are underwriting service in insurance industry, Loan approval in banking industry etc.. We need to identify modular business capabilities and then expose them as a service.  Autonomous  services should not share  or use resources from other services. A autonomous service remains stable and available, even when changes are done in other services or their resources are not available. of course, in real life,  autonomy will be limited  by trade off between autonomous and shared resources cost.    

The ABC2 of a service represents  Address, Binding and Contract. The ABC2  of service defines how service oriented interaction take place in service oriented  IT world. This is shown in the figure given below. 

A service provider makes available a ABC1 as an IT service.  Service provider publishes the service to well know DB location , called service registry. Any authorize service consumer can login to the registry and download the wsdl. From wsdl, service consumer can generate a service proxy . Using service proxy, service provider can interact with the service by sending and receiving messages as shown in following diagram:- 

wsdl contains second ABC of SOA i.e. ABC2 whose details are given below:-

C for Contract or Interface of the service. Interface defines following  

Operations supported by the services. 

The Input message structure  for each service 

The output message structure for each service

For defining messaging structure, some standards are SOAP, JSON, XML, WS-* etc.

B stands for Binding

The transport protocol through which input and output messages should be exchanged. Some examples of transport are http, JMS, SOAP etc. 

A stands for Address

Every service should have  have an IP address on which  service consumer can send the messages for invoking a particular operation provided by the service. 

The interaction shown in above diagram in called service oriented interaction. Service oriented interaction is easier (from consumer perspective)  and more agile(Stable service with less cost of change,if any, in terms of money and time,)  due to following reasons. 

• There is a physical separation between ABC2(Implementation) and ABC2 interface (WSDL). This means ABC2 implementation can be changed without requiring a change in WSDL.  
• Interface(WSDL) should be design in such a manner that they remain stable as any change in them is likely to break the consumers. 
• Autonomous service are less likely to change due to changes in other services or in their resources 

A knowledge driven enterprise

It was great Peter Drucker who coined the term -”Knowledge Worker”. Drucker defined the knowledge worker as one who has more knowledge and skill than his manager. Drucker definition was appropriate for 20th century knowledge worker. The definition need to change for defining 21^st Century knowledge workers. A 21^st century knows worker is one who can do knowledge transformation – from explicit knowledge to implicit Knowledge and vice versa. Explicit knowledge is a knowledge which can be clearly documented and made available to all concern in an enterprise for consumption . Enterprises also have another kind of knowledge – the implicit knowledge. Implicit knowledge resides in the mind, attitude and behaviour of its workers. Employees learn explicit knowledge and apply it solve real life problems and issues. In the process they can acquire implicit knowledge. It is extremely difficult to identify implicit knowledge and document it as explicit knowledge. In a truly knowledge driven enterprise, knowledge worker do the transformation of explicit knowledge to implicit knowledge and vice versa.

A knowledge driven enterprise should document explicit knowledge and encourages its employees to consume it, use it and acquire implicit knowledge and the document it as explicit knowledge which can be consumed by others. 

It is continuous knowledge transform process which makes an enterprise a truly knowledge driven enterprise as shown in the following  figure. 

In a truly knowledge driven company, there are large number of 21^st century knowledge worker who are continuously engaged in knowledge transformation. In this process they continuously out learn and out innovate the competitor and provide truly sustainable long term competitive advantage to their enterprise. 

Enterprise architecture with Single perspective Parallel thinking at time

One of the definitions of SW architecture is “A series of related, contextual and logical decisions with trade off analysis “. According to Martin Fowler “An architect should take only those decisions which are of high undo cost”. Normally an architecture decisions are taken in VUCA (Volatile, Uncertain, Complex and Ambiguous) world. Moreover, most the architecture decisions need to be taken in a group. Hence, it is necessary that architecture should have a framework for architecture decision making which can be easily used by individual or a group. 6 thinking hat is a framework invented by Dr.Edward De Bono. Dr Bono is one of most profound thinker of the 20th century. Each hat represents a particular perspective through which we look to the various aspects of the decision. The summary of the perspective represented by each hat is give below 

Blue Hat: Initiation and Overview 

White hat: Relevant Facts and information 

Red hat: Human dynamic – Emotions, Feelings,

Yellow hat: logical thinking 

Green hat: Creative thinking 

Black hat: Risk identification 

Blue hat: Conclusion and summary 

I strongly recommend that you go through 6 youtube video’s in which Dr Bono himself explain 6 thinking hats framework. The further details of each of the 6 hats are given in the table later. 

The essence of 6 thinking hat based decision making is that it replaces argument based thinking  with Parallel thinking. 

When we indulge in argumentative thinking, ego’s come into the picture. At the end of the argument, some group members do not really accept the decision in their heart. While parallel thinking means that at any given time, everyone wears only one hat. For example, black hat represents risks and their consequences. The key is that each member wears black hat when risks are being discussed. Nobody is supposed to talk about any think other than risk identification as along as he is wearing black hat. This lead to parallel thinking. While doing parallel thinking, each group member demonstrates its thinking capability in identifying risk rather than countering some other member point of view. Hence, egos don’t come into the picture. The greatest advantage of parallel thinking is that by the time, we have gone through all the 6 hats, Decision is self-evident. So, nobody is looser, irrespective of the decision made. Another advantage is that all the group members are more likely to own a decision arrived via parallel thinking than the decision arrived after an argument based thinking. 

6 hat thinking and decision making can be done in individual or group mode as long as we follow following simple rules   

1. Use the framework in time box and iterative manner. You can have iteration at individual hat level and also at all 6 hat level 

2. Use parallel thinking in place of argumentative thinking. 

3. Asked context based questions in each hat 

4. Delay the final decision to the next responsible moment. 

Hats can be used in any order but in most of the scenario, using blue hat in start and end will help. 

How 6 hat thinking can be used for enterprise architecture, is shown in the  below. Here again key is to ask right questions in the context of given hat type. Once we have the right questions, we are always likely to get right answer. 

6 thinking hat 

Blue Hat: Initiation and Overview  

What are we trying to achieve in this specific initiative?

What are the mains Goals?

What are Non Goals? 

What are the constraints and assumptions?

What are the boundaries of our enterprise?

What is in scope and what is not in Scope?

What processes we need to follow for bests results?

What are the resources we need?

White hat: Relevant Facts and information

 What information is available?

What information is needed?

What information is missing?

What is the information Gap? 

How to get missing information? 

Enterprise Vision,Mission and Values?Goals, Objectives, Measures, Initiatives?

Enterprise Operating Model?

Stakeholders and their concern?

Processes? Entities?

Business rules/events/task?

Enterprise baseline Architecture?    

Green Hat:Creative thinking

New Ideas?

Alternatives?

Possibilities?

Hypothesis?

Visions? Base line Architecture?

Target architecture? 

Gaps?Opportunities?Mafia Offer?

How can you develop shared vision and relevant understanding among all stakeholders?  

Yellow hat: Logical reasoning

Benefits? Value, Value sensitivity?

Make it work? Define base line and target architecture 

Best way to bridge the gap?

Trade off analysis?

Where is the Value addition?

How does it work?

Black hat:Risk Identification 

(Do not over use this hat}  

What are the risks?

Risk management strategy?

Red hat: Human dynamic – Emotions, Feelings, Intuition

Intuition? How are stakeholders feeling and emotions?

What are your/team feeling and emotions?

What you can do to reduce the emotions conflict 

Blue hat: Summary&Conclusion
What is the Decision?
Which stakeholder are positively impacted and which one are negatively impacted?
What is the right time to communicate the decision?

Have we covered all the scope and nothing but the scope?
What are the real value add?
Lesson learnt?Stakeholder satisfaction? 

Bono further advocates that thinking is skill and like any other skill it can be learned. An architect may have high IQ/EQ but he can use his IQ/EQ only if architect have a well-developed thinking skill. The more we use 6 thinking hat frameworks, more we are likely to improve our capability to take better decisions 

SOA School Certified SOA Architect

Recently I become a SOA school certified SOA architect. For completing this certification, I attended a 5 day training program for SOA architect. This certification requires me to pass following exams: 

1. Exam S90.01: Fundamental SOA & Service-Oriented Computing
2. Exam S90.02: SOA Technology Concepts
3. Exam S90.03: SOA Design & Architecture
4. Exam S90.08: Advanced SOA Design & Architecture
5. Exam S90.09: SOA Design & Architecture Lab

In addition to above, I also referred to following books from SOA School/Thomas Earl: 

After going through the training program and above three books and then passing all exams, I understood the big picture on how to do SOA. My understanding of big picture is shown in the figure given below:  

From above picture it is clear that Thomas Earl and his team have defined a framework for service enabling an enterprise. The main part of the big picture is explained below:  

1. Enduring principle of good Software engineering 
2. 7 strategic Objective of SOA  
3. 4 Characteristics of SOA 
4. 4 types of SOA
5. 3 types of services 
6. Robust SOA 
7. 8 principle of SOA 
8. SOA design pattern 

1. There are certain principles of good software engineering which are never out of date.  These principles are – Decomposition – Functional/Process, Separation of concerns. Modularity and abstraction. We should keep these principles in mind and apply them in appropriate manner whenever we are doing SOA. 

2. Whenever we are doing SOA, we are trying to achieve 7 strategic objectives which represent a specific target states. We need to ensure the all the stakeholders (SH) have common understanding of these objective. It is important that all SH understand that these objective are strategic in nature. Achieve these objectives, initially requires   time and investment till we reach a tipping point. Tipping point is a state when enterprise has right mix of services and can create new service with service orchestration. Once we reach tipping point, we can start getting the real benefit of SOA in terms of Agility and low life cycle cost etc. 

3. There are 4 characteristics of SOA – business, enterprise, composition and vender neutral centricity. If our SOA effort does not represent any one of these characteristic, then we are not doing right kind of SOA. 

4. Services are the most important component of SOA. We can classify services in three types - task services, entity services and utility services. These services form separate layers and represent an example of application of principle of separation of concerns in SOA. 

5. Whenever we are doing SOA, we are going to do 4 types of SOA. The first is creation of SOA domain .service domains are decided by decomposition an enterprise into logical, coherent group of services. The next type of SOA  is architecturing a specific service in a particular domain. Third type of SOA is service composition. Service composition architecture type represents how new services can be created by composition and re-composition of existing services. If we can achieve above three types of SOA, we will able to create a service oriented enterprise which will have organization agility at business level and a vendor  neutral, enterprise centric IT system which will have low cost of ownership and higher ROI. 

6. We have 8 SOA design principles which can be applied when we designing a specific service . The following figure shows how SOA design principle can be applied on different aspect of a service  

 7. We have large number of design patterns which can be applied as proven solution for solving recurring problems which we encounter during our SOA initiative. These design patterns can be best understood by classifying them into – Normalization, canonicalization, centralization and generalization category etc. Normalization patterns help us in ensuring that there is no redundancy of capabilities across different services. Canonical pattern help us to create an enterprise or domain wise common data/messaging models. This helps us in minimizing transformation and reducing complexity. Centralization patterns ensure that for every capability there is only one service at enterprise level and capability can be accessed only via its official contract. Generalization pattern help us to create services which logic generic logic and are agnostic in nature. Such services have maximum potential for reuse.  

8. We should also not forget 4 pillar of SOA – team work, CCF, discipline and governance and balance scope. In SOA we team work across multiple teams which may not be co-located and belong to different enterprises and groups. We need a common communication framework. All the stakeholder need to have common shared understanding of SOA. For this to happen, every individual need to unlearn and learn many new things. Development of common terminology across all the teams is essential to SOA success. Scoping in SOA project is a big problem. Neither can we have a very wide nor very narrow Scope. What we need is to have a balance scope which should  been arrived  keeping the enterprise in mind and capability to comprehend and execute by various teams. Although these 4 pillars may not sound very jazzy but they are critical to SOA success. 

 If we are able to service enable our enterprise in the manner described above, we will able to meet 7 strategic objectives of SOA or desired target state of a service enabled enterprise. 

From Code to SOA

Writing code that works in all possible states is difficult. Writing code that not only functionally works in all possible conditions, but can also be easily understood by others and then changed relatively easier, is far more difficult. In the words of martin Flower – “Anybody can write the code that works but only a seasoned professional can write a code that can be easily understood by other human beings”. Far codes to be easily understood by others, it should not have two characteristics – Code scattering and code dangling. Code scattering results when same concern can be is implemented in the code in multiple places. This results when we apply copy paste operation while righting code. Code dangling results when we try to implement multiple concerns (Process logic, Business logic, Glue code for API calls, Data access logic etc...) in the same place . Both code dangling and scattering result in a code which is difficult to understand and hence change. In traditional API and SPI (service provide i/f) based application model, writing code without code dangling and scattering is extremely challenging task . 

We can easily define enterprise SOA with dangling and scattering concepts. We need to replace code scattering and code dangling with concern scattering and concern dangling.   A   service enable enterprise should have each concern implemented in one place via a specific service (No concern scattering across multiple applications). Further, each service should do only one specific concern (For example process service should be focus on one specific concern - process co-ordination and should delegate other concerns to other services (e.g. getCustomerRating for getting customer rating). In a truly service enabled enterprise, for each functionality, there should be only one service and it should be executed in only one place. In SOA.what has really changed is the perspective or viewpoint through we look to  software development, from the perspective of departments and functions to the perspective of an enterprise.Unit of software development has shifted from department/function specific applications to enterprise services which are centralized.  

Below is the example of centralized and shared service - 

 The  advantages of such services are clear 

 Easier to maintain from a centralized location – No concern scattering 

 Easier to extend – No concern scattering and dangling 

 Easier to scale via load balancing 

 Low cost of ownership due to heavy reuse 

Working In Architecture Spaces

The way we approach to work is important in any discipline in general and in software architecture world in particular.  A SW architecture need to work in following works spaces

ü  

       Preparation Space

Problem space

Solution space

 Opportunity space

The following figure explains each of the above spaces 

Architecture Spaces 

AS& SMART – Architecturally significantly specific, measurable, attainable, reusable, reusable and testable requirements.  

Mafia offer/suggestion – An offer/suggestion which is so good that it is easily accepted by the respective stake holders.   

We seldom spend any time in preparation space explicitly. We need to spend time in preparation space explicitly so that we can be ready for the assignment in hand. Professionals in other fields, e.g. sports,  spend considerable time in preparation space and their ultimate success depends on how well they spend their time in this particular spaces.  Out of the above four spaces, we are going to spend maximum time in solution space. However, preparation, problem and opportunity space are point of leverages. By spending some additional quality time in these spaces, we can considerable reduce time spend in solution space. We add more than proportional value to stakeholders.

We should not work sequentially in these spaces. We should able to move from one space to another space depending upon the context and practical situation. While working in one space, we should be totally isolated from other spaces. For example while working in problem space, we should not think about the solution. While working in any space, we should always keep the current context in mind.  

It is also important that some time we work in opportunity space. In this space, we should ask some probing questions as mentioned in the above figure. This can help to innovate in process, product and services and next practices.  Mark McGregor is right when he says that we  do the catch job by implementing best practices and gain real sustainable competitive advantage  identifying and implementing next practices on continuous basis . In future only those software professionals will survive who not only follow best practices but can think of next practices, next generation of products etc. on continuous basis. Hence working on opportunity domain and asking probing question will be critical  success factor for future software architecture professionals. 

T Profile – Specialist Generalist

From quite some time, professionals have been classified into two categories – Specialist and generalist. Generalists are the peoples who know something about everything, but have little deep knowledge and skill in area . While specialist are the people who have deep competencies in one area but have virtually no knowledge or skills in any other areas. Even in software world professionals are classified into two categories – people and technology. Professional with people skills are suppose to have some magical skill in dealing and communicating with other peoples and need not have any technical skills. While professionals with technology skills are obviously suppose to have deep technology skills but very little skills in dealing with people and communication. The really important question is, professionals with which type of profile will be required in current and future world. Once thing is certain – in future, every professional will be required, not only to work efficiently, but also continuously innovate. Innovation means doing something new and different which deliver enhanced value for money to all stakeholders. In the world of software, professional, who will have maximum potential to innovate, are likely have T profile. People with T profile, on one hand will have breadth of knowledge in software and other related disciplines; on the other hand they will also have deep competencies in few areas. Innovation required a wider horizon with deep insight. Only T profile can meet such requirements. Every software professional should have a knowledge and skill portfolio in line with T profile. He should make an explicit attempt to acquire his new knowledge and skills as per his knowledge portfolio. Google allow its employee to devote 20% of their time on projects/ideas which are purely decided by the employees themselves. A software professional should also devote some % of his work on his knowledge portfolio. He should periodically review his knowledge portfolio in order to align it to ever changing field of software development.