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

Was at the open group conference at Bangalore and spoke on “Enterprise Architecture and Keeping your business relevant”. Was off to native and could manage to attend the second day of the conference at Phillips Innovation Campus.

Initial Talk was by Jason Uppal on how EA was used to solve problems in the heath care industry and his experience in the same with some case studies.

Some interesting perspectives on initiatives from the Open Group to take Togaf body of knowledge to colleges along with Computer Society of India and an effort to popularize it apart from being used by the industry alone.India ranks third in the list of Togaf certified candidates and increasing year on year. This was briefed by James of the Open Group.

EA and the Developing World

Far away countries such as Finland and Brunei are also adopting Togaf and there is growing list of developing countries such as Mongolia  which also is adopting Togaf for overall streaming lining of IT services. This was presented by Vish Vishwanath of CC and C solutions.He also walked through the penetration of EA in these markets and how EA can significantly be used to solve newer technology adoption issues. Developing countries will have to go through the same curve where EA can play a good role in packaging and getting your business / IT strategy right. This market is hugely untapped and really be a good case in point to explore and would most likely a candidate where future success stories would be crafted. 

Keeping Your Product/Solution Relevant

Spoke on using EA to help keeping the business relevant. Touched upon how a reference architecture helps create a north star to follow. How a large company can stay agile and make quick turn around as it is said making “Making an Elephant Dance”. Most large corporations are now focusing on learning this key skill. Gave a brief presentation with 18 list of TODO’s for a company (product/solution). Irrespective of the size of the company the ability to dance to various market and customer tunes is what helps it stay on top of the curve. The presentation details are shared here. All of the slides have 18 TODOs listed ( in no specific order ) and each category needs a deep dive into what can fit well for an organization specific context. Overall a handpicked set of initiatives that help a product or a solution to be relevant in today’s times. Even implementing a few of these initiatives to a reasonable degree of seriousness can create the hockey stick effect on your annual performance report , which is the last slide of the presentation. 

Commoditization of EA

That apart there was a talk on how EA is being packaged and off shored an IBM perspective by Sreekanth. This dealt with the issues of putting solution architecture work miles away from where it is being consumed and how technology has progressed in making this happen. How customer’s are now adopting this mode of delivery and look forward to having a robust process framework around this to help with getting predictable and estimates for the same. Ideally they would like to have better control on the work pieces assigned to the team off shored to and be able to estimate and bill accordingly. As a lot of things are new on this front as always it takes sometime to stabilize things on this front. Have come across SAP and other vendors opting for a packaged implementation points sort of a things which is like a work break down structure for your activity at customer location. World is indeed getting flat including off shoring innovation work  till the point that you are not sure your idea is going to fly. In which case more clarity emerges and all trial and product pivoting also is getting off shored.

There was a talk by Hari from TCS on a case study of who they used Archiemate to map customer requirements and showcase value to the customer end user on use of the same. This is a neat initiative that is picking up momentum on tying together business and IT together. UML is for techies and not all business nuances can be conveyed using the same. The business folks are not UML friendly and a free format diagramming visual standard such Archiemate is useful in helping bridging the gap between the two.

Disconnect between Archiemate and Togaf : For people entirely new to these they need to be treated separately and does not pose a problem. For folks coming from the Togaf world there seems to be a missing perspective ( data ) which archiemate has across all the layers and gives primary prominence to Business , Application and Technology at least in the views. The data part of the details are implicit across the visual representation of Archiemate and quite embedded as a part of Business , Application and Technology instead of being treated separate. Quite understandable as bringing data architecture at a overview level can pose the trees get coverage instead of the forest. Anyway it is a step to bridge the divide between business and IT. Have heard about how this standard is helping many approach architecture diagrams without being overwhelmed at the outset with semantics of the new standard or other intricacies of UML which for a person from the business would be hard to scale upto. Certain regions have a good adoption of this standard and certain countries are ok with BPMN / UML or arbitary or No UML as it is referred to where every organization creates a standard that suits its needs the best with legends etc.

A weekend well spent discussing things that matter and can change lives and our part in the same.Attending conferences always keeps you relevant and of course helps one in keeping abreast of what is happening around.

]]> https://sairam.eturnti.com/open-group-conference-2014-bangalore-where-is-ea-now/feed/ 0 https://sairam.eturnti.com/techgig-talk-why-should-you-care-to-create-a-reference-architecture-in-your-organization/ https://sairam.eturnti.com/techgig-talk-why-should-you-care-to-create-a-reference-architecture-in-your-organization/#respond Wed, 01 Jan 2014 05:20:47 +0000 https://sairam.eturnti.com/?p=479

Key Take Aways from the Presentation

How to relate to Enterprise Architecture Frameworks such as Togaf and Zachmann and make it work for your in your Organization ?

• Why do need an architecture in place in a product or solution ?
• Why are different views to architecture important and why is important to create the one that you are interested in ?
• How do you apply framework level separation of views to create a reference architecture ?
• What is the role of architecture vis-a-vis agility? How much architecture is needed for the hour ?
• How will people in the organization benefit from having a visual representation of architecture. It is there for all to see.

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural / managerial ladder in your organisation can augment your skills and can benefit from this training.

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

More people in the line wanting to become architects/managers , join an architectural practice, better your existing knowledge levels and people wanting to climb the architectural ladder in your organisation can augment your skills can benefit from this training. 

What is EA is it a body of knowledge , bunch of frameworks, tools , practices , methodology , best practices ? Know what it is to know what goes behind EA practices and how they are applied to situations and derive value and showcase improvement in the organisation.

Past sessions had the following mix of people attending this training developers,leads, managers,architects, business analysts , consultants working on IT projects, directors and people who are , going to be part of enterprise projects and wanted to know more on how they are managed and executed.

Following are  some of the aspirations of the candidates who attended this training in the past.

1. How are EA projects managed ?

2. How are EA metrics captured , benefits measured and calculated ?

3. What are the EA frameworks and how are they used and applied in principle ?

4. How is this applicable for product development ?

5. Justify the usefulness of EA and measure overall effectiveness of an EA program.

6. Apply these principles to IT and infrastructure projects.

7. Want to lead a team of EA architects and manage an EA project .

8. Usefulness of Togaf and Zachmann and how to apply them to real life projects and derive value. Understand these frameworks and their relevance in setting up an architectural practice.

9. Convince management on architectural best practice and able to contribute to architectural decision making in the organisation.

10. How can we keep EA technology/platform agnostic ?

11. EA and agility where do they mix and match ? Is it really feasible ?

12. How to keep EA projects in iterations well managed and accountable ?

13. Want to know what this buzz EA is all about and what does it mean as I am currently doing architecture work.

Become good at what you are doing, impress your managers,coworkers by attending this course and finally add value to yourself.

Drop a mail at asketurnti[at]eturnti[dot]com to book yourself or click here.

On Similar lines found some useful links from a linkedIn discussion group that recommends some commonly used EA tools to set up an EA practice. Archie Mate is familiar the others aren’t .

Open Source Tools for Enterprise Architecture

http://www.enterprise-architecture.org                                                 http://www.modelsphere.org/index.html                                                                   http://archimatetool.com/                                                                                               http://www.adoit-community.com

Although the venn diagram shows the buy v/s build concerns in reality software has many interfaces and sides that a buy v/s build is never easy to arrive at. But echoed below are some common rants where the decisions turn this way or that way and choose either and do not get lost in the quagmire of decision making.

Buy

• We do not have the capability.
• That is not our core competency.
• We need it as an add on piece and is not our core function
• The cost of buy is much less than the one of losing the customer prospect.
• We do not have the time and the resources/skill set.
• We need to scale up fast to newer technology and not lose customers
• Packaged software which is time proven has already gone through the twist and turns.
• What is the shelf life of this product will it change hands or get

 Build

• We need to develop something unique which will be our core strength going ahead.
• We can wait and build it ourselves.
• It will be our IP moving ahead.
• We will build components whose life-cycle is in our control.
• We could outsource this as well which means it is a kind of a buy with a different connotation.
• We like what the buy guys have to offer but it does not meet our requirements.
• What will happen to our legacy code ? Is there a reuse or can it be repackaged with a new interface for some more time.
• What new skills do we need on board? How much will be the wait time before we can roll it out using agile/RAD processes?

Both

• Will build some will buy some
• Will buy and still build some interface , connectors , glue code to interface the solutions.
• What about the internal organisation buy in are all the stakeholders in synch.
• Do we have people lined up and having loyalties of one v/s the other.
• How do we decide which way to go ? How much of either to choose and replace the other ?
• Look unemotionally on where you want to go as there would be a lot of forces for either debate. Stick to one approach and ensure the approach is agreed upon by all before the roll-out.

Post this debate once you have arrived at say three solutions A, B and C. Now using a weighted average method you can rule out any competing concerns. It is another thing if you have arrived at your architecture by white boarding and have done your due diligence. Also you can use some sort of cost benefit analysis to narrow down your choices. Use what works you to turn your enterprise around.