Systems Thinking and Togaf how can EA help ?

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 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

Go Blue Green with your deployments

Wanted to introduce an agile architecture tip here.

People talk of agility all the while but a lot of best practices need to support agile such as all the things that devops brings to the table such as CD/CI and everything continuous. This means that there should be an ability to deploy code into production going through dev / test / pre prod / prod and everything in between that you can plan for releases in a product or solution. Unless an organization pays complete attention to getting the CI / CD practices upto date there can be no real agility as it is known the last mile in development is the place where the code gets pushed into production and there are many challenges right from developers saying the code works fine on our machines to the QA team and system test people having another opinion. Continuous development , continuous integration and continuous deployment makes all of this possible as it is quite possible to push code into production from development environments .

For agile practices like these you could use green blue deployments techniques. A little about the green blue technique

, it involves maintaining two environments one green and the blue environment where the exact production like environment is maintained end to end from the web server / app server , operating system and the database. This quite difficult to achieve end to end . So organizations make do with getting either the web server  / app server replicated and have a common database. In that case using a router in between the traffic is routed to either the blue server or the green server.

ROUTER – —-> (test.sampletrail.com) > Blue Server ( let’s say this is the main server )

ROUTER ——> Establish temporary connectivity with the Green Server ( Standby server in case the main server goes down )

When you need to divert traffic to the green which has the latest code and patches while blue has the old code and server status. The blue can still be considered as the fall back server in case the green server gives up and is not able to handle the traffic and if found unsuitable or not stable. This option gives organizations the confidence to keep the system up and running and as they say is one of the ways in which the lights can be kept on. This is most often used in many RFC and RFPs from clients

There can be many edge cases there such as while the transition is happening to the green and then back to the blue what about the transactions that get posted via the green. If the database is unified then the challenges in this not wrecking the system can be limited based on the code in the application logic. But it is implied that the design level changes are taken care, to rollback or reconcile such transaction postings by means of application logic.

When the transition is happening only read only transactions are possible to ensure there is minimum changes to the consistency of the system. You can have this setup in a virtualized setup on the same physical machine or different machines.

Always keep the option of toggling between the blue green states so that it ensures complete flexibility in trying out quite and application patches with a lot of agility.

What are such practices that you use currently or want to be updated on do let me know ?

References :
https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html
https://aws.amazon.com/blogs/compute/bluegreen-deployments-with-amazon-ecs/
https://martinfowler.com/bliki/BlueGreenDeployment.html

Success today requires the agility and drive to constantly rethink, reinvigorate, react, and reinvent. – Bill Gates

Picture Courtesy : Cloud Foundry blog

The Buzz about Togaf as an essential Transformation Framework tool kit for Architects

 

 

 

 

 

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.

Kiran , so 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 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

 

What does Car Service and Architecture Compliance reviews have in common ?

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.

Standards and an Architect – Helps one to manage application complexity better.

I am attending a Cloud security standards industry meeting today evening on how to harmonize the cloud with a lot of standards that are flooding the market. In fact there are no unified cloud security standards today, each vendor be it AWS , Microsoft , IBM g, Google have their own standards.  In the back drop of this thought that the role of an architect to look for standards , pick and choose and make the best choices should be part of one of his/her key skill sets.

The below diagram is from the Open Group https://www.opengroup.org/architecture/togaf91 . As you  can see it is made up of the a whole lot of standards right from HTTP / CICS ( old world mainframe ) to RPC to ORB to xml over http etc. It has even screen scraping used as an integration touchpoint so as not to disrupt the existing architecture and move ahead with minimal changes.

As can be seen from the figure below the latest and greatest technologies have been used to make up the entire architecture. You may say that this actually looks like my company architecture. In fact in one of the companies they mentioned that their current architecture looks like this to the T and were checking if it was actually cut paste from their architecture documents. In fact that is how architectures evolves in an evolutionary fashion in small increments over a period of time . Once it becomes as large and complex then it is not easy to keep making changes and enhancements to the architecture and still expect it to remain flexible like the way it used to be.

If you carefully look at the architecture below then to maintain its lifecyle we would need people from all the diverse skills sets such as an ORB , RPC which were no doubt the latest and the greatest technologies at one point of time. But if you have not standardized the interfaces over a period of time then we need to worry about getting people with those skills sets in the company when putting ads for those skills sets on indeed.com or dice.com would show very few takers. This obviously creates a challenge for the key people entrusted with the task of owing the product or solution on how to gets folks to maintain these layers / enhance it / modify it etc. If the architects have a standard plan of say all UI layer code to talk to the middletier using the standard set of interfaces all business facing APIs at the business layer need to follow the standard practices. The below diagram would perhaps have around 4-5 different protocols and others would have got consolidated or sunset based on the different releases or solution delivery cycles.

What is the cure for all of these is to have a Reference Architecture which promotes the uses of known standards while building architectures.

Now looking at SECURITY as one part of the list of things that make up our application stack .And if we have to look at the security pieces that make up our application architecture.You can create a stack of Security across the Business , Data , Application and Technology layers additionally.

 

 

 

 

 

When we look at setting standards for Security alone these would be the brief list of things that you need to take care of. At an enterprise level security will not be complete unless physical security is accounted as well. This would ensure how IT resources man , material and IT assets are safe guarded in the event of a calamity.

So on the standards journey an architect / senior IT professional needs to take care of how to organize and plan for use of standards in their realm of work.

Leaving you with a standards trivia ” USB 3.1 doubles the speed of USB 3.0 to 10Gbps (now called SuperSpeed+ or SuperSpeed USB 10 Gbps), making it as fast as the original Thunderbolt standard. USB 3.1 is backward-compatible with USB 3.0 and USB 2.0 ”

So much about standards