Saturday, May 28, 2016

What kind of code should an Architect write? by Swapnonil Mukherjee

Referred Link - https://www.linkedin.com/pulse/what-kind-code-should-architect-write-swapnonil-mukherjee?trk=pulse-det-nav_art

What kind of code should an Architect write?

What kind of code should an architect write or rather What kind of code CAN an architect write?
A lot of people perceive an architect to be a detached entity perched high up on an ivory tower with little or no interest in what is happening down below in the bazaar.  The reality however is that architects can and do write a whole lot of code. I give you some specific examples.
Domain Specific Frameworks
Even though generic frameworks like Spring, Play, RoR, Django exist in each stack, there is still a need to bake in the domain on top of such frameworks and build what is essentially a domain specific framework. Such frameworks  create the core entities, their life-cycles and the business constraints under which those entities operate. They are effective in ensuring that large code bases conform to a single architectural and design style and use a set of common libraries for common tasks. Architects, because they interact with business closely are in an unique position to create such domain specific frameworks. These frameworks don't have to exist on Day 0. They can be re-factored from existing code as well.

Test Harnesses
The testing landscape is extremely fragmented today. Some use functional testing as their primary quality assurance mechanism while some are innovating to the extent of using deep learning and other such clever algorithms to find bugs faster. An architect is in a unique position to understand the testing needs of a project and for example decide between Cucumber or Fitnesse.  They can create test fixtures and test runners and lay down a common set of mechanisms to conduct unit and integration test. Developers can then plug their data and tests into those fixtures rather than assembling everything from scratch.
In a similar vein they can also create Performance Test harnesses and write code that establishes effective Benchmarks for critical sections of the code. 

Automation and Engineering Process Improvement
Automation can be anything that removes manual and error prone tasks. There is gradle, jenkins, chef, puppet, docker and a multitude of such tools that can be used to develop automation frameworks. I recently developed a jenkins plugin that could run a Sonar diff between builds and show the issues added and their severity between any two consecutive builds.

Skeletal Architectures
Skeletal architectures or Just Enough Architecture as I would like to call them is essentially a set of smallest viable components wired together end to end simulating one or many important use cases.  They are really helpful in creating and validating the integration architecture of the would be system. The architect who designed the solution in the first place is in an unique position to also build a bare bones version of it and prove to the world that it really works!

Proof of Concepts for Architecture Validation
We architects propose new libraries and frameworks all the time. To reduce the risk of failure in incorporating those libraries it may be necessary to build proof of concepts to prove that those shiny new frameworks are fit for the purpose. This also something that an architect with probably a few developers can build.
Master Coders
The major piece of code that an architect doesn't write are the actual business use cases. But he reviews them , if required corrects them and ensures that they conform to overall architecture, design patterns and the business constraints of the domain. In effect he also plays the role of a Master Coder.
So what about Solution Architects that don't code at all? I too have been on assignments where I have only been asked to draw boxes and lines. But those roles are slowly but surely dying out. I am seeing the role of an Architect more or less morphing into something more like a Principal Engineer. But that doesn't mean design is dead. It isn't. There is still value in the Software  Architecture Development and Documentation process and it should remain the the bread and butter for any Architect. However with architecture itself becoming a commodity (how are the boxes in my mobile-web or big data architecture different than yours mobile-web or big data architecture?) just drawing boxes and lines isn't going to cut it for too long. 
By writing code Architects can bring a lot of extra value to a team. That's exactly what I have been doing. It is just that people don't seem to understand what my role is.

No comments: