Thursday, December 28, 2017

How Organizations Can Restructure Themselves to Churn Out Home Grown Architects at a Rapid Rate



Abstract

Every software architect has played the role of a software developer, but very few software developers will get the opportunity to play the role of an architect in their future. Evolving into an architect or at least a good one takes years of dedication to technology, its concepts and emerging trends as well as best practices. There are too few decent architects out there and at times the scarcity of architects is quite alarming. Alarming as it may be it is still not too surprising though since we all know the abilities and skills expected of an architect are quite demanding these days and are very rare to possess. It's quite a stressful, responsible and critical role in an organization that is required to steer projects towards success. Even though there is a huge demand for quality architects in the market they still remain a scarce breed and they come at an ever increasing high cost. This article talks about how an organization can rethink its structure to address the underlying issue for scarcity of top architects and focus on developing home grown architects rather than depending on high cost lateral architects.

1. The Generic Structure

The most crucial element in a software organization is the quality of its software developers. The second most crucial element is how these developers are molded into having an architect's mindset for the future. In most organizations' structure the developers' core skills get lost amongst the various duties and responsibilities he must perform as he climbs up the professional ladder. This generic structure that consists of software developers, tech leads, business analysts, project leads etc. leads to the dilution of technical skills and the resource loses focus on areas that he expected to concentrate on.

This leads to the creation of generalized resources rather than resources with specific skillsets. Even in organizations that focus on creating technical streams there is too much overemphasis on specific roles within each stream that actually dilutes the quality required of a good actual architect. Most seasoned enterprise architects will tell you that there are only two kinds of technical resources i.e. 1) Developer 2) Architect, everything else in between is a pure overhead and results in dilution of the qualities required by a good technical resource.

2. The Simplified Structure

Very few techies these days have the pure raw passion for coding and development. A harsh reality is that most software engineers are keen on working just for a couple of years as a software developer before rushing to a management school. The even harsher reality is that a lot of software development abilities get lost in the unnecessary hierarchies built into the various streams in an organization. The technical skills of a resource loses priority and techies are expected to take on lead roles and management duties as well. Whilst those streams are absolutely necessary for those individuals who are keen to pursue management streams, a conscious efforts should be made to preserve the core techies from getting swept away by such streams.

Core techies are a rare breed and need to be nurtured and preserved if an organization aims to generate their own breed of competent and well versatile architects. Simplifying the organization structure or at least the part that applies to technical streams is the most important step in achieving this goal.

3. The Way Ahead

Simplifying the organization structure in no way means scrapping out the existing structure since those too are very crucial for producing the next line of management, solution architects and business analysts hence these streams have evolved. However it is important to modify the streams that are meant to generate core architects for the organization. As mentioned earlier, core technologist considers only two basic hierarchies in the technologies stream i.e. you are either a developer or an architect or both. All other levels in between serve as nothing but hindrances or filters that dilute the qualities required to become a strong architect.

An architect is someone who has stayed very close to development for many years before he goes on to create conceptual designs for systems himself. It is imperative for him to be conceptually very strong and this can happen only when he has "been there and done that" himself. Most technical tracks or structures give various other roles to techies which include UML modeling, designing, some even involve requirement gathering etc. These tend to divert the architect away from coding thereby weakening one's concepts gradually over the years. Gradually coding complex architectures by being a developer for all so many years is one of the best ways to gain a proper insight into the architecture domain from the inside out. Some of the ways to simplify organization structure with respect to the technical streams are explained below.

3.1 Persist with only two roles in technical stream

There should be only 2 major roles in a technical stream I.e Developer and Architect. The main reasoning behind this is that we would want to develop architects who are fresh with coding and have not been out of coding from past many years. When architects are out of touch with coding they become 'conceptual architects' rather than 'practical architects'. 'Conceptual architects' are an extremely dangerous breed since they come up brilliant architectures that might be altogether un-implementable or may not be what is actually required. This is one of the major reasons for project failures and disasters especially from a technical standpoint. However having technical resources work as developers until the very last stage before transitioning into architects helps avert the production of these 'disastrous' architects but rather develops well rounded, grounded and practical architects who are not afraid to roll up their sleeves to get the job done during production and go live scenarios.

3.2 Develop multiple sub roles for the developers

Developers should have fulfilled multiple roles, all of which are related to coding before transitioning into an architect's role. These roles are put in place to ensure that the resources work on different aspects of a project. The most common mistakes that happen in technical streams in various organizations are that technical resources are indeed assigned multiple roles as he grows up the ladder but those are mostly in areas around design, requirement gathering and other high level documentation related activities. This results in technical resources having less time to exercise a concentrated effort on coding and on understanding the workings of different architectures they are working on. For example: developers with 1-3 years on experience can focus on low level coding activities like user interface, validation, front end business logic etc. resource with 3-6 years' experience can focus on coding on business classes, business logic and data transfers between objects, resources with 6-9 years of experience can focus on coding the framework, overall architecture and common reusable components.

Having such roles defined ensures that the technical resource remains as close as possible to coding before he transitions into an architect's role.

3.3 Versatility on multiple technologies

It is very important to ensure that the developers who aim to become architects work on numerous technologies. This helps give the developers a better insight on the architectures in different technologies. It also broadens one's perspective in different ways that is difficult to describe. Working on multiple technologies help architects to understand "real world" problems better and equips them with a better ability to prescribe practical architectures for the same.

4. Conclusion

In conclusion, all we need to do is have a minor change in our thinking and perception of the technical stream and restructure the same to reap huge benefits in terms of cost and productivity. Change is the only constant in life and we must change and adapt our structures as well to better suit the modern requirements. By doing such kinds of minor restructuring within the technical streams in an organization we can help develop an architect engineering machine within the organization that will help us save costs and design better and more practical solutions whilst churning out efficient home grown architects thereby reducing the organization dependencies on high cost lateral hires.




I am a Technical Architect with 13+ years of experience in Architecture, Design, Development and Deployment. Have performed Architecture Assessments, provided technology consulting and created strategic roadmap for multiple customers across different BU's. Core areas of expertise are Enterprise Architecture, Application Architecture, SOA, Systems Architecture, Integration Architecture and Systems Architecture. Working mainly on Microsoft technologies at the moment.

No comments:

Post a Comment