There are many a times when you went to give your cell phone for a repair and the company just charged you for fixing an issue with the UI but opened up a whole new issue of now the battery drains faster.

We shall look at Systems Thinking and why is it important for Senior IT professionals and architects.

Basic Tenets of Systems Thinking :

Improving the performance of the parts of a system taken separately will not necessarily improve the performance of the whole; in fact, it may harm the whole.
Problems are not disciplinary in nature but are holistic.
The best thing that can be done to a problem is not to solve it but to dissolve it.

We should look at systems as a whole as opposed to solving problems in bits and pieces. It is also about defining the problem as many a times if the problem definition
is not correct then we end up solving the wrong problem. In any enterprise product or solution we need to understand the issue that the system has many perspectives to it
many norms / rules that apply to them and we need to see how the problem manifests in its entirety and not in isolation.

For Example if a man wants to be healthy and loose weight get him to a treadmill is an easy reply. But if you need to see how he wants to really loose weight the healthy
way then we need to checks his DNA for obesity issues, health checks , his food habits , his neighborhood, work life patterns and how all of this in its interplay helps him to loose weight
holistically.This is what gets ignored in traditional symptomatic treatment of issues usually achieved by procedural thinking.

On the same lines when you need to look at the architecture of a product or a solution then we need to look at it as a whole and not in parts.

Architecture has many dimensions enterprise , business , data , application , technology . Viewed from an other perspective it has a logical and physical part to it such as abstract and concrete , logical and physical , generic to specific , expandable to bespoke architects , highly portable to built for a specific platform . The list goes on….

Amidst all of these conflicting stakes what is the best way to look at your architecture as a whole by look at the parts in relation with the whole. TOGAF® Framework as an EA framework helps you on thinking these lines on how various architectural concerns make up one big picture.

An EA framework helps you to compartmentalize the concerns while being focussed on the organizational end goal. This way you can look at the whole while tending to the parts.

A logging framework needs to enhance the performance and decides to encrypt the data on the wire but performance can be compromised if the tradeoffs are not looked at.
A product where user experience is made more intutive but not has the issue of maintainence overheads which are highly unfavorable.
A product that works well but does not have enough market traction or rather does not promise customer experience.

The laundry list can go on if you do not think on Systems Thinking as a means to fix this.

What is your experience here on such situations where you had to look at the product or solution as a whole.

PS : “There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion.” ― Donella H. Meadows

Just saw the above job ad from my linkedin feed and this one talks about the company needing a security with a T skill profile.  Meaning have deep dive skills in one or two areas and broad based skills in other areas. Togaf that way has been mixed and matched with other architect skills like Security , Infra , Business , Data , Domain , Functional , Technology architecture domains. This helps a professional have a broad based skill or outlook when they reach a certain career progression path. So one typically gets into the question of what is needed to be an architect . Here is a link on what would be needed to become a good architect for the ones who may want to make that career progression. Steps to transition into an architect path .

The ancient definition of an architect was that he/she should be a many of letters , arts , science , literature , music , architecture ( building / landscape ) etc. Meaning that you should be a Da Vinci to really have that title. But it is not that bad if you are planning to become a solution , IT or enterprise architect. As we all can’t be Da Vinci’s to fill that slot.

If you are wanting to make that transition happen or be exposed to that body of knowledge to help you with having an architect’s mindset then TOGAF® framework comes to the rescue.

Mind you it is not really needed to have a certification to become a good architect. But certifications expose one to a body of knowledge that companies and peers value. You may possess this knowledge by virtue of being in a certain role or vantage point in a company.

Every skill you acquire doubles your odds of success. Scott Adams

I had given my car for a service recently and it so happened that I was driving it around the city for couple of days post the service. Was getting a wobbling feeling on the left front wheel of the vehicle  it then occurred to me that there could be something that could be a problem on that side of the wheel.Took the vehicle back to the car clinic only to find that the wheel post service as fixed back in place using only two nuts out of the four . It was lucky to have noticed it at least at that point of time. Did advice the floor manager to put back the wheel tightening part in the vehicle checklist before commissioning the vehicle that it is fit for the roads. It was an eye opener for the importance of having set rules and checklist for anything in your life , be it planning a trip with friends and family , checking items off your to do list or even it that means delivering software or architecture the right way.  A checklist’s value is immense and is only known when you have missed something in the case of the car the crucial wheel nuts itself . As we could see that the lynch pin if it goes missing then it can be life threatening. Similar is the case with creating a product or a service , it can be mission critical if you miss that important nut or bolt that shall latch the end product.

Let’s us look at the above process which is detailed as a part of the Open Group Togaf which talks about creating an architecture compliance review process . As you can see the whole process starts off by having an architecture lead who leads the process and continues the whole chain of activities in between looks at a checklist to see all the nuts and bolts are in place and tight.

So What can be few of the checklist

1. Hardware and Operating System Checklist

• How does the system design impact or involve end-user devices?
• What is the quantity and distribution (regional and global) of usage, data storage, and processing?
• What applications are affinitized with your project by similarities in data, application services, etc.? To what degree is data affinitized with your project?

1. Software Services and Middleware Checklist
2. Applications Checklist
3. Security Scrutiny Checklist
4. System Engineering Methods and Tools Checklist.
5. Application Integration Checklist….etc 

So what is your story around checklist . We all agree that they are the must have in an software professional’s toolkit.

]]> https://sairam.eturnti.com/what-does-car-service-and-architecture-compliance-reviews-have-in-common/feed/ 0 https://sairam.eturnti.com/value-stream-as-an-essential-tool-for-architects/ https://sairam.eturnti.com/value-stream-as-an-essential-tool-for-architects/#respond Tue, 23 May 2017 07:09:20 +0000 https://sairam.eturnti.com/?p=1479

This topic came to my mind while I was chatting with my cousin over the weekend who was presenting on this topic as a part of the CII ( Confederation of India Industry ) conference. He works for a mechanical company and was to present the business benefits in his company. They had optimized their existing set of process to reduce the cycle time of churning new products. They had mapped their existing process structure from the point where the raw materials are procured to the place where they undergo various levels of transformation / integration to finally give that polished output. This happens as a part of various business process work flows. He had his presentation ready and was to explain how useful this technique is for extracting maximum enterprise value in an organization.

What does Value Stream mean to an architect ?

A value chain diagram provides a high-level orientation view of an enterprise and how it interacts with the outside world. The purpose of this diagram is to quickly on-board and align stakeholders for a particular change initiative, so that all participants understand the high-level functional and organizational context of the architecture engagement.

Porter’s Value Chain analysis is used to develop a focus on those activities within your Company that significantly add value and thus give you a competitive edge. For instance, if your team is very good at analysis and design such that you can define and bound a problem better than anyone else in the world, you could put in a process to continually implement new design and analysis methods and disseminate that throughout the organization so that you are always the best. And you can lead with that in your marketing efforts by calling that out as a “feature” and highlighting the benefits to the customer of lower development cost, more robust solutions, etc. Value Chain Analysis is a way to get at your key competencies which create differentiated products and services.

Although the above diagram can look like more of an MBA kind of material trying to unify the business problem and the IT solutions to plug the same. As you progress in your careers you are expected to understand both the business and the IT sides of the equation well and this is a useful tool to help one with the mental model for the same. This is very useful in getting discussions started with the customer and quite handy during consulting and internal process revamp exercises.

As far as architects are concerned their efforts should be focused on activities that bring the highest business value to the organization and the customer. This needs them to understand in the sense of what constitutes primary and secondary activities that bring value to the end customer. Once this is understood the organization can pull the strings in the right direction and focus its efforts in the right direction. Here is leaving you with a brief intro video on what is value chain https://www.youtube.com/watch?v=g8p2H7EvoGM.

Most often getting business architecture requirements right is a challenge and it means there are two types of people who need to converge at a common point to where they could make sense it each other. The business people are concerned with the business side of things and look at the picture from an angle which could be quite different from the IT folks. For example the IT team is worried about building requirements that are more better versions of working software or rather refinements in releases but the business is concerned about what business value will this piece add to the overall product strategy or solution point of view. Many a times it so happens that there is no clear articulation of business value and organizations spend time and effort in producing waste or MUDA ( Toyota / Six Sigma ) prefers to call it. This can happen because in the name of taking up an initiative a wrong requirement was envisaged as having to be completed.  Many a times the requirements although is an art and science by itself and needs to be done with the right focus as all the downstream actions based on this can create mis alignment in the vision and mission of an enterprise. So is there is definitive prescription to doing this , how is this similar to user stories or epics that agile teams talk about . User stories are not enough to detail all possible requirements more so when they depict the end to end system goals where aligning business and IT is paramount. This being the case there needs to be a structure to capture all the actors and details that goes into getting a business scenario right.

Recently been to an IT company where the issue was product owners hand over requirements over email or chat sessions or simply over a phone call. It was said that requirements not getting correctly scoped was the single most productivity loss and created enormous amount of wasteful downstream activities. What has been your experience here ?

Most people undertake a Course or Certification when they are in between jobs or are looking to test the waters on their market potential. A certification kinda of validates that need as you are better off from the herd when you have that certification. But a certification alone will not help you to get there. Most concerns of people wanting to play the role of an architect would be .

1. I have played various roles but have not been officially given an architect title in the company . How should I move into one ?
2. I have all along been into lead roles / managing projects and delivery but never played the role of an architect in a project.
3. I have worked along side different architects and have seen project / delivery folks donning architecture roles . Can I do the same for my career progression ?
4. You want a role change having been a manager for many years now you want to see the other side .
5. You have got your hands dirty with having worked on many different products and solutions and now want to spend time architecting with the customer in mind as you better understand product and solutions.
6. You have been all along working alongside products and solutions and now can better steps into the shoes of a customer to understand what they need ?
7. You want to apply all that you know regarding a domain but are not customer facing to be able to influence and add value to the final architecture ?
8. Are you in the midst of all the above kinds of queries ?

Want to read more such architect snippets like these please mail on maileturnti@sairam.eturnti.com to subscribe.

What is common with Steve Jobs, Mark Zuckerberg both of them have being huge successes in what they offered to the world. They stand for make a dent in the Universe and yes they did it. If you see both of them they did play at intersections and ended up disrupting more than one industry. Steve Jobs combined design and technology and made owing hardware akin to buy vintage art or jewelry. Before him people had given up on hardware which was not good looking and aesthetic, he created awe inspiring products by combining design and technology. Similar is Facebook which combines social and technology to have connected almost all of the world.

Like wise it is when it play at intersections you have multiple opportunities of disrupting more than one field. Likewise when you see many fintech start-ups they are all playing at various intersections.

You have banking intersecting payments.

Payments intersecting retails

Payments intersecting travel

Payments intersecting eCommerce

Loan industry intersecting real estate

CRM industry intersecting credit card industry

Hospitality industry intersects Banking

The list is endless and the possibilities are very many. Playing at intersections has more than one advantage as you are exposed to ideas which flower and cross pollinate when they collide with other ideas and give birth to fresh new design and offerings. This is not possible when you work in isolation in one area. Most often these work best when not compartmentalized in siloed states , they need a continuum or an ecosystem where all people involved in the value chain to the end customer are brought on the same table and it can lead to fusion and myriad colour all coming together.

Enterprise Continuum from the Open Group is one such initiative that aims at connecting the buyer, seller and the internal teams of a value chain together if you were to look at it from Michael Porters famous value chain. This continuum has enabled many an industry to stay connected with their entire ecosystem such as partners , sellers and their own teams delivering on many mandates. One such example of how this would work in practice would be let’s take the example of a Salesforce team which has many partners that it is depended on it and all such information relevant and shareable to both parties will be made available. This means all that can be shared preserving all IP and NDA issues shall be made seamlessly available to both connected parties across the board with the same level of understanding in taxonomy and jargons which bring all parties in an engagement on the same level. The Enterprise Continuum takes this further and extends it to have internal teams , partners and vendors all on this connected platform. Once this clarity is there in the ecosystem it becomes easy to build, integrate, brainstorm, enhance or do anything is required for the moment. This might sound utopian but if implemented well with the support of a visionary leader, it has the power to transform most issues arising out of working in silos across industries.

Dow went from being a Inorganic company to being an Organic Company to being a plastics company to being a food company. These are not simple transformations or transitions. Now they are embracing the culture of innovating at intersections at the intersections of material science , biological science and physics.

Why Enterprise Continuum of TOGAF Amidst Of All This Talk of Innovation ?

Enterprise Continuum from the Open Group is quote “The Enterprise Continuum provides methods for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.”.

In short the above diagram shows how a company can go about organizing its organization artifacts from generic to specific. The more you move towards foundation architectures it would be generic and the more one moves towards the right towards organization specific architectures you narrow down the scope and genericity. The diagram has both architectural and solution assets which allows for abstraction from logical to physical which is fundamental to good architectural work. As you can see a company or organization can starts it journey by beginning with Foundation Architectures and move towards Common Systems Architecture where you have narrowed down your architecture from blue sky generic architecture where the scope of building the most generic architecture is toned down to concentrating on the core domain de-scoping the operating systems and network architecture portions of the same. Now you focus on the industry that you are working on and store industry specific architecture in the industry architecture section. Let’s say you are a developing a banking software then all the other industries that you closely work with such as CRM , Payments , Retail , Financial Services, regulatory services, credit cards will find a place in the industry architecture section. But your focus in the year one of architecture / product development shall be only on building banking software which happens to your core focus area. Again you as a company keeping adding features to your core product, you will refer back to the industry specific architectures to add differentiators in your core product. When you are marrying a core banking product with a payments feature then you potentially refer to the industry specific architectures section of your enterprise continuum and then pick the relevant architectures and go about building your feature. Now this is a value add that Enterprise Continuum brings to the table where you as an organization developing a product also refers to architectures specific to your industry and this can help you in innovating at intersections.

Have such an integrated concept for knowledge and artifacts managements can go a long way in helping a company with innovation at intersections. This means you can work along side product, industry boundaries and if done well you are poised to disrupting more than one industry. Enterprise Continuum also can be created for your specific needs and reflects your journey and what artifacts you as an organization is interested in and help you go back and forth and exploit potential innovation that can happen at boundaries.

Open Group has a extension of this concept where industry specific artifacts for oil and gas, telecom, mining, supply chain are available and companies can become members and look at what is of interest to them by being part of the community and benefit from the same.

They say it is fun “Innovating at Intersections” Enterprise Continuum of TOGAF has an answer to this.  Would love to hear your thoughts on the same.

IT Transformation , Digital Transformation , Keeping Your Lights ON while you make changes to your bread winner applications in the Enterprise, move certain others to the cloud, rework on your SMAC strategy, going digital, change your tires while your speeding Enterprise needs to overhaul itself at the same time needs to keep moving and least not loose time at a pit stop.While all of these sound easy to write about but when faced with the challenge of turning your enterprise around , you need a mindset, culture , appropriate tools, talented people who understand the nuances of the change , tools required and how to go about it.

Firstly Mindset : You need to know that people need to change the way they think about the they are standing on a burning bridge with water beneath if you were to borrow a line from the Nokia chief’s mail to its employees. Unless people perceive it this way change is difficult to force it down their throats. Fluidity in all process and people boundaries such that people can reach out and interact with folks across their immediate process lines. This needs a mindset change which can happen when their is strong management support towards moving away from silos and encouraging decentralization.

Be Proactive ALWAYS – Look at the windscreen and not often at the rear view mirror

Usual mindset is look at time, money , resources and progress once you have finished your product or solution. Instead create a pro active process measurement and improvement dashboard where you are measuring everything while moving instead of reflecting when it is all over. This is process independent and no matter which agile methodology you use or which project / process framework you are currently executing. The idea to embed metrics in your journey can be right from the beginning where you look at

1. Review all internal process.

2. Requirements stability

3. Change Management processes

4. Your speed of execution , ability to close projects / activities within time and budget.

5. What market forces are currently influencing your product / solution.

Once you start improving these factors then your outcomes or business results follow on account of these steps or measures.

Tools at the Pitstop

One of the ways to capture these would be to implement a balanced scorecard.

Digital flexibility: 

This key skill would mean how often are you ready to change gears midway and skill / re-skill yourselves when you hit transformation roadblocks.

Integrated Operations data : Ability to respond to complex process data and act on them in real time when transformation is underway.

Experimentation and POC hotbeds : Ability to rapidly experiment test beds where simultaneous low cost fail fast experiments and proof of concepts can be carried out and more importantly reduce the cost of failure.

Data driven decision making : Put check and capture data of all kinds which can be useful to driving change and arrive at decision based on those.

Eliminate , Eliminate all kinds of communication barriers across teams. How do you stop one . Meet review and action on the points that are found as causing delays. Delays can be anything from waiting for snacks in queue in the evening to not getting appropriate sign-offs in time. Teams working on agile communicating with non agile or semi agile waterfall teams can slow things down. Use your own process tailoring to get across these barriers.

Promote quicker decision making using the following concept decentralize implementation and centralize interoperability

Wiping the dust off the screen , spare tires and everything in between.Re work on your strategy when there is a downtime .

What to do when others are racing as hard as you as well.

1. Remember what you are transforming is not only a technology issue and see it is as a business problem and technology is a leverage. Most often companies do not learn

2.  Always eat a part of the pie instead of full fledged transformation on all cylinders. It is nice to say we are changing the whole machinery while the vehicle is moving instead it is better to change the parts one at a time. It is not easy in a large transformation program but things become much easy to test waters when strategy is broken down to segment and then to the solution level. Let’s say 5 competing product lines are ready for transformation and then out of them only 3 are handpicked for transformation , then out of these 3 pick 10 % functionality and iterate and continue this till you can increase your velocity.

3. Get people to meet the change agents often instead of hanging organization change mandates across the hallway, coffee stations , places where your resources spend most time. Else they end up being fodder for light banter during coffee breaks. Strategy should be de-centralized and no one person’s or team’s prerogative to succeed. And communicate , live them day in and day out instead of them being poster board material.

4. Setup innovation and design thinking workshops across the length and breadth of the organization for people to go about doing there jobs with more fun and independence at what they are doing. Do this when during happy days and not so happy days in the company. Make this part of your core routines then it becomes easy to flex think and act nimble.

This is not the full list of course would love to hear from you on what points went to your refueling enterprise journeys.

Image credit : pixabay

The US Library of Congress is one of the largest libraries where knowledge of most facets of humanity such as arts, science , astronomy , folklore, traditions , math,architecture etal is stored and preserved over years. This has survived many a century or two as we march in the 21st century and is a laudable effort in knowledge management by any standards. When you want an organization to be built that it wants built to last kind of foundations then it is imperative that the knowledge management surrounding it should be quite solid and future looking.

Knowledge management is an essential component to the Enterprise transformation exercise. The reason being if you are not sure where you currently are then it is not possible to go where you want to go ? It is like having a blueprint of what artifacts you have on your product portfolio and get to know how they all fit in.

Knowledge is like data in a database and management often would how you would manage the data and give meaningful information around it. Knowledge management would be about easy retrieval of information which would mean that you have to a good job of configuration management system around it this is a given and true of all configuration management systems.

Typically in an organization knowledge management would involve storing design documents, code , configurations , tar/war files and all such information that is useful to them and would need to retook at them from time to time.But most often in companies you have people asking around saying do we have an RFP to respond to that client request. Do we have an reference architecture document that would help us is not reinventing the wheel and respond to the client from a similar geography without having to go through specific region specific customization needs. What this means that all of this promotes for greater reuse and reduction of rework and help more better time of an organization’s time and resources.

Do you know what all can be stored in an Organization’s repository ?

1. Industry Standards Information

2. Internal Standards Document

3. Project Closure Documents

4. Governance Log Details

5. Artifacts of all kinds in a company ( code , docs ( SRS , user stories (if you are an agile shop ), architecture specs , business process docs, diagrams,matrices,catalogs)

6. Solution Specific Artifacts

7. Reference Architecture models for the product or service that you are positioning yourself.If you are new to reference architecture then here is a link to a video explaining the same.

8. Have you ever thought of linking this knowledge base to the extent that the information sharing makes sense to your client , partners and vendors ecosystem giving all the IP protection , NDA etal in place.

This is exactly what enterprise continuum in TOGAF paves way for and help an organization create a knowledge ecosystem that will help organization make faster procurement decisions, buy v/s build decisions and simply provide for agility during business transformations.Enterprise Continuum in TOGAF is a concept that has provisions for all of the above and is indicative of how an enterprise should structure its assets if you want to thrive in the knowledge economy. If you know what you have well then you can go ahead and add / subtract the features needed. Most companies at times think it is an overhead along with their day to day run the business model to keep their knowledge base updated.

Most often unit / organization heads have this moment of ground shifting from under their feet when asked “How are we go from this product to the next version of the product?” or “What is the effort involved in getting this product multi currency enabled?. These questions become much easier to answer if you have a strong knowledge management practice. These facts cannot be gathered on their finger tips but with working towards a culture where the knowledge within the company is available to one and all and most important easily structured and retrievable would decide how good it is at business agility and moving ahead.

Image Credit : wiki

Baseline as per the wikipedia is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change.

Most of us can relate to that statement which means the product or solution has come to a certain maturity in abstraction of its features and now you can call that a baseline. Some companies work a great deal to arrive at a baseline which is what they have worked over months , years to finally arrive at one milestone in their journey and call it the baseline. Now the title is why do some companies decide to throw it away. We shall see how and why this happens ?

Togaf has a concept of going about iterations on how you can go from one state to another in your organization transformation journey. There is a baseline first and target first approach when you go about iterating across its phases for architecture development.

Baseline First : Firstly you go about considering the edifice for building future work is your current baseline and then it becomes the starting point for doing any work henceforth. What this means is that you as an organization has significant has accumulated a lot of collective knowledge and arrived at the baseline which is still relevant and useful in going about the organization churns.Lets say you are a n oil and gas major and all the data models,process workflows,architecture documents ( business,data,application and technology) are at a point where they need further pruning and tailoring to meet the new market realities. And hence any work that you do keeping this as the basis will end up being called as baseline first approach.

Target First Approach : With disruption in every industry at times your baseline becomes completing irrelevant and new forms of transacting , doing business gets precedence. Examples of this would be Banking industry being caught in the wallet war from google,apple etal and further danger from the block chain , bitcoin and newer forms of currency exchange without the middleman. When this is more true for your current state then the baseline or the accumulated knowledge in the organization is found to be not very useful to go ahead with the organization transitions.

In reality this is not very true as there could be pockets sometimes huge areas of the existing knowledge base that can be turned / fine tuned to better meet market or product relevancy in the market. In the case of bitcoin based transactions disrupting banking for example the banking fundamentals such as credit / debit still would remain the same. But again it is upto the organization to see what parts of the baseline is relevant in your journey and then use it to your advantage. This needs good brain storming withing the company weighing the pros and cons and then take it forward.

What’s true in practice

Reminded of a joke that was going on in a company .They estimated that they would need a 100 developers working on the baseline for about 1.5 years to overhaul the product and make it market ready then there was a side remark saying give us 30 developers “throw away your baseline and we’ll rewrite the product afresh in six months.

So the fact of the matter is throw parts of your baseline away where it makes sense keep the ones that aid your transformation. This needs sound existing knowledge of your baseline and also where you want to go. Many organization find this to the biggest challenge “Where are we going and how ?”

Having the clarity of baseline first and target first approach helps …..

Would love to hear from you on what occasions did you have to chuck away your baseline if not great. If so how much of it was throw away and what portions could you keep ?

Image Credit : https://www.flickr.com/photos/strelka/