Route to production - as a technical architect

The role of a developer is pretty much clear and concise. However the role of a technical architect some what gray. Generally, a solution architect should be able to deliver a blueprint to a technical architect and walk away. I understand that this is an extremely naive way of looking at things, but you get the idea.

Hows thing are done

My role as a technical architect was focused on guiding the development team, enforcing the governance and adhering to the essence of the solution blueprint. From the face of it, this sounds pretty awesome.

I loved being part of the development team and cutting code. I know numbers of architects who are expert Microsoft Visio or Word users. But I prefer the a middle path.

I made choices of the frameworks and patterns that should be used for the solution. I looked at each problem in details, devised solutions and attempted to get the team onboard. I did fail number of times because there were disagreements how things can be done or what framework to use.

It was sometime easier to do the work myself. I would knock off the code within few hours which would have taken a week or so for a developer. In hindsight I think this was a bad decision. I should have tried to get the team onboard but I learned my lesson.

More I spend time with the team, I realised that I was neglecting my duties as a technical architect. I needed put in place deployment, packaging, monitoring and auditing. We used SCOM for some of these, and other alerting mechanisms. I had to talk to other teams and vendors to ensure production environment was ready for the solution.

Lonely 

I think leadership of any form force you to a corner. It does not matter you sit with the development team or not. If you are making decisions for a team, you will be isolated.

I committed lots of code the solution but no one was there to help with my work. There was no one to talk to Infrastructure team or Networks. I had to carve out time do this. I had to document the design decisions. This took time and I and only I did this.

Even though the developer could shoot off to the pub, I had spend countless hours updating developing documentation and liaising with other teams.

Day T - 1

The day before the release to production is always challenging and nervous. At this point I would  have spend countless hours designing, developing and most importantly championing the solution, but nothing prepare you for T - 1.

Day T

This is when the solution is available for the public. Great and humble experience!

Day T + n

This is the day I received the first production incident.

The cycle never stops unfortunately.

Route to production! - as a developer

I have heard many stories and quotes in the past that directly points to the title of this post. This is my take of the subject.

There is no doubt that every developer (including myself) would like to spend many hours perfecting the software engineering art. We love our design patterns, SOLID principles, frameworks and runtimes. Any passionate developer can spend hours talking about these subjects. These aspects of software engineering is so important that without it, any project can get out of control and possibly fail.

My journey

I was fortunately to be a developer on a very large and complex enterprise solution. I also played the role of technical architect and solution architect in two separate medium/small solutions. In this post I would like to share my role in getting the solution into production.

As a developer

Being a developer is a fantastic experience. I read in many articles that we stand on the shoulders of giants. I think that is absolutely correct. The open source movement, stack exchange has brought the developers of the world together.

I loved being a developer of the large and complex solution. It was a payment system which had numerous integrations and challengers. In fact the solution may look quite complex at first glance, but it was broken down by context (e.g. refunds, payments). This breakdown allowed any developer to focus on one area of functionality.

The team itself was large, and had an amazing breadth of knowledge. Some days I would spend hours going through my colleagues code as it was an art!

I was happy and joyous. I would have long lunch breaks and discuss the latest trends (e.g. microservices, functional programming) in the industry with my colleagues.  Sometimes, the debates inevitably got heated! but that was the fun of it.

The solution was owned by a solution architect and a business analyst. I never took too much notice of these guys, as the stories and tasks that were allocated was descriptive enough. Once in a while I would consult and ask the intent and the context.

The colleagues outside the team did not like the solution architect. I heard stories of him storming out of meeting and being rude to some. This was very strange as none of us in the technical team felt any hostility. The solution architect use to tell us that few hours he spends with the technical team was the best time of the day! We took it as a pinch of sugar and salt!

The solution had multiple components deployed across various systems. I never had to worry too much about the deployment topology. The code I wrote, went through the normal development cycle and ended up in production. I did know the end-to-end system. I could describe each component and how it relates to the business function and why it is needed.  I was proud of my work, and I received positive feedback from the customers. That was a great feeling! Each day, I would take a cursory look at the logs to ensure there is nothing odd.

The deployment pipeline was a heavily automated. From the engineering aspect, the only manual step was the selection of the appropriate package to test, stage and push to production. The quality assurance (QA) activity was mixed (automated and manual) as we had to depends on other teams to confirm.

Keeping aside my social life, I had the opportunity to look at the next shiny thing! The life was great!

Reflecting on the title of this post, I was not too involved with how and where the solution got deployed. I had queries from other teams but nothing to pull my hair out. Most of the queries were related to check whether this or that feature is working, what account, what permissions etc.

The solution now sits in production serving millions of customers each day without a sweat. Perfect!

Whats next

The times change, how teams are organised change and yes, change is everywhere. In the next post I am going to discuss how my role changed and what impact that had on myself.

Useful AWS commands

• aws iam list-users
• Gets a list of users in the AWS account. Returns full details of the user object.
• aws iam list-users --query Users[*].UserName
• Gets a list of user names in the account.
• aws iam list-policies 
• Returns a full list of of AWS policies which includes AWS managed and customer defined.
• aws iam get-account-password-policy
• Returns the password policy of the account. If none defined, returns "NoSuchEntity" error.
• aws iam get-account-summary
• Returns the limits of the account. Useful to find out what the limits and request increase from AWS support.
• aws iam list-policies --only-attached
• Returns a list of policies that are attached. Useful to find out what policies are being used.
• aws iam list-policies --only-attached --scope Local
• Gets a list of policies that are managed by the customer that are attached (ignoring AWS managed ones). Useful to detect how many customer defined policies are being used.
• aws iam list-entities-for-policy --policy-arn "ARN"
• Lists the users, groups, roles and resources that are using the given policy. 
• aws ec2 describe-regions
• Returns a list of regions available. In order for this command to work the "region" in the CLI. If the "region" is not specified we can use "aws configure" to configure a region.