Category Archives: Blog

Don’t you want to be a data scientist, architect, painter, lead guitarist at a music band all at the same time?

Leave a reply

 

As IT professional’s architects it is said that we belong to more left brain types meaning involved in logical, data focused, critical thinkers and as we progress we are supposed to develop our right brain as well. As IT professional’s architects it is said that we belong to more left brain types meaning involved in logical, data focused, critical thinkers and as we progress we are supposed to develop our right brain as well.

Creational side versus (right )  the Operational side (left )

In the initial stages of your career we are mostly left brained but as we progress up we are supposed to use both the sides of the brain well as jobs that need us to look at the holistic big picture expects us to be both right and left brain oriented. As technologists we tend to become caught up with data, numbers, facts and figures and not perhaps creativity, intuition, feeling and over all visualization capabilities. As architects and IT professionals’ people come in various shades of these polarizations. No one is either totally left or totally right brained for that matter. There are always shades of grey when we talk about the gray matter. As IT professionals we need both of them in good measure when we need to don different kinds of roles. When we are deep down with the nuts and bolts architecture we need to exercise the left brain where there is a lot of data and analytical reasoning and logical analysis needed to arrive at solutions. But when we need to go visualizing how the whole solution fits into an enterprise standpoint or from a business standpoint in the ecosystem then the right brain which is good at leadings us into imagination can helps us with those kinds of situations. As it is said as an architect it is good to fail on paper than on practice. So the more you can fail on a blueprint or a prototype you would have saved yourself from failing in actual where the time money and dollars cost is higher.

As senior IT professional we often times need to shift across these patterns where we need to be focused on the things that matter now (nitty gritty) versus the things that really matter in the long run (big picture). You definitely need to focus and defocus at the same time. This needs practice, practice and following up on your skills.

Need a Mix and Match of skills: Need to look at the market fit, big picture, vision, mission and product viability versus need to look at whether we as a team have the skills to match the requirements are we aligned in the right direction are we able to sift through a lot of data and look and find patterns that are hidden in them. Which runtime to pick against the other, which middleware to choose from the other and which ones are cost effective and also future proof at the same time. Complex processing decisions that the brain needs to factor which needs that you need to up your game to be able to see things from that perspective.

Some quick hacks that people have used to shape your two sides of the brain.

1. Talking to random people outside your sphere or area or interest.

2. Meditate ( Clicked but very effective )

3. Try writing with both hands ( looks childish but many vouch for this )

4. Spend time with all age groups more so with people outside of your age group.

5. Listen to music, art, walks alongside nature and pieces of history.

6. Have quite of few of my friends pursuing different areas of interest completely orthogonal to their existing vocation such as makeup artist , drummer on the side , food truck business , rose cultivator etc etc.

7. Go find your bliss to be more effective.

Systems Thinking and how the TOGAF® Standard can help ?

Leave a reply

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

Go Blue Green with your deployments

Leave a reply

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® Framework as an essential Transformation Framework tool kit for Architects

Leave a reply

 

 

 

 

 

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

 

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

Leave a reply

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.