Check any of the global job boards for Architecture-related positions (e.g. Enterprise, Solutions, Business, Information, technology, etc.) and you will quickly see the obvious: Only a very small percentage of all Architecture jobs are non-technical. The majority of the demand is for architects who come with, both, deep technical skills and broad business & IT experience. The expectation is that architects are people who are expected to roll up their sleeves, get their hands dirty, and contribute real working solutions. And, with the reality that enterprises are aggressively moving toward heavy automation paradigms like Continuous Integration and Continuous Delivery (CICD), DevOps, and Agile, it appears that demand for architects who only create pretty pictures is waning, while the demand for the Coding Architect is rising.
Defining the Non-Coding Architect
Before getting into the definition of a Coding Architect, it’s important to understand what a Non-Coding Architect is…
A Non-Coding Architect is an Architect who is almost never expected to get into detailed design or expected to build, install, test, deploy, operate and support things. Non-Coding Architects usually spend their time creating documents in support of things like “the Architecture” but rarely deliver much more. Business Architects are the most common examples of Non-Coding Architects but there are sometimes Enterprise Architects (EAs) and Solutions Architects (SAs) who also have few expectations to get their hands dirty.
There are some common challenges that many Non-Coding Architects deal with:
- They’re constantly begging for funds to support their ideas for improving the organization.
- When enterprise finances get tough, people who are not in hands-on critical roles are usually the first to go. Since Non-Coding Architects are perceived to deliver nothing but documentation, they’re often quickly perceived as expendable.
- A person who is not technical enough cannot design a comprehensive version of the Architecture for the enterprise, because a significant percentage of The Architecture is always technical.
- Because Non-Coding Architects rarely leverage automation, it takes them far longer to collect, organize, and share data about the enterprise that is critical for supporting the development of The Architecture.
- Over time, Non-Coding Architects lose many of their technical skills because of lack of practice and involvement. As a result, they lose touch with the business customer’s expectations for how complex technologies need to be used to positively impact how the business competes. This means that, over time, it becomes more difficult for the Non-Coding Architect to contribute value to different enterprise solutions.
- The Non-Coding Architect has challenges installing and evaluating new and evolving technologies (i.e. performing research) to understand different ways to improve business capabilities.
- The Non-Coding Architect can’t design and deliver shared Enterprise Services that can help optimize the enterprise by maximizing delivery and quality while reducing costs.
- The Non-Coding Architect is rarely called upon to be a leader, especially when it comes to the delivery of high-risk business critical projects, products, and services.
- Non-Coding Architects are often perceived as Picture Drawers, meaning they have the stigma of not delivering more than just documentation.
Defining the Coding Architect
A Coding Architect (sometimes referred to as the Engineering Architect) is an Architect who is expected to actually design, build, test, deliver, and/or support certain technical solutions in their enterprise [in addition to delivering diagrams and documentation], regardless of whether they are Enterprise, Solutions, Data/Information, Business, or Technology Architects. They usually have significant experience in not just a few but many different technologies and can dive into and help solve problems across very diverse technical and business areas. A Coding Architect is always expected to have real skin in the game.
There are some clear benefits to establishing Coding Architects in an enterprise include but are not limited to:
- Coding Architects can perform Non-Coding Architecture functions but the reverse is not always true.
- Because they’re deeply involved in critical Business and IT systems, they have high visibility and importance to the enterprise and its leadership.
- They can be used to take over and deliver high-risk high-impact projects.
- They can be used as utility players that can be moved around the organization, in times of need.
- They deliver tangible solutions that simultaneously increase productivity and quality while reducing costs (especially for other technical teams).
- They can be tasked with complex business-transforming technology research.
- Because they leverage significant amounts of automation, they almost always deliver key architecture artifacts much quicker. This is, for example, because they can use automation to collect far greater quantities of far more accurate data about the enterprise and its current state, at far lower costs than manually performing the same work..
In summary, the Coding Architect can and does perform any work the Non-Coding Architect is expected to perform, and more.
Comparing Coding versus Non-Coding Architects via a common Use Cases
Use Case #1: Creation of Strategy, Planning, and Transformation Artifacts
One of the most common Use Cases that highlights the effectiveness of Coding Architects vs. Non-Coding Architects is the work it takes to develop strategy and transformation documents. Anyone who has ever performed such work knows some fundamental truths associated with this type of work:
- There is often a great deal of data to collect, clean, process, and analyze that is needed as a foundation for developing such documents. The larger and more distributed an enterprise gets (e.g. imagine very large conglomerates that offer products and services in many different industries), the more complex this problem becomes.
- Creating/harvesting and maintaining contextual relationships between all the data leads to even more data that must be maintained for reuse, over time.
- Manual collection of all this data takes tremendous amount of time/labor, is fraught with human errors and requires high human labor costs.
- The quantities of data are so large that upper-mid-size and larger enterprises often rely on big brand management consulting firms to come in with large teams of people to help with the data collection, cleaning, organization, and processing for the purposes of developing strategy-related architecture artifacts.
- Significant portions of such data are constantly changing in most enterprises, especially the larger enterprises.
- Strategic plans require regular updates that depend on all this constantly changing data (e.g. quarterly or semi-annually) or they need to change because business direction has changed, requiring even more new data.
- If you don’t have automation in place to collect, help analyze, and help manage the data, human labor will cause the above to start over every single time you need to update strategic planning documentation.
In the case of Non-Coding Architects, they 1) manually go out to collect the data they need and restart the process of data collection every time strategic planning documents need to be updated, or 2) they look for ways to secure funding to pay other developers (who report to other managers and who have other development priorities) to build such automations, ultimately tying such automation and ongoing changes to long and expensive release cycles.
In the case of Coding Architects, they build the data collection, analysis, and management solutions to help facilitate future endeavors themselves, realizing that putting such automations in place increases architecture artifact output, reduces the long term number of hours required to perform such work, raises the quality such architecture artifacts, and reduces the long-term costs to produce and maintain them.
Use Case #2: Creation and Sharing of Enterprise Critical Knowledge
Another common and critical Use Case is that of Enterprise Knowledge Management (EKM). The data and content required for the success of the above Use Case #1 (i.e. strategy and planning artifact creation and maintenance) is the same data and content that is needed by many other people and systems around the enterprise to perform their own work. Since, in the case of the Non-Coding Architect, the data is collected and created manually, most resulting architecture documents/artifacts are squirreled away, into hard to find and use repositories, almost immediately outdated because the underlying/foundational data has already changed. On the other hand, in the case of the Coding Architect, the regularly changing data is more frequently fed into a live Enterprise Knowledge Repository (EKR) that is not only used for architecture functions but which is also shared throughout the enterprise, helping many people in many different roles and organizations to also receive, analyze, share, collaborate on, and help improve the data (which in turn leads to better data for the previous Use Case).
The Coding Architecture Culture
The Coding Architecture Culture is a culture that expects constant and continuous tangible solutions delivery from their architects. The expectations are that architects are senior and very knowledgeable resources that can be used to make the enterprise deliver smarter and faster (i.e. higher quantities, higher quality, less cost).
Enterprises that adopt a Coding Architecture Culture and who establish very technical Architecture Organizations are usually those that place the highest value on competitiveness, believing that the best way to be competitive is to adopt a continuous and very technical forward pace. These enterprises are the ones that espouse the Automate Everything philosophy. Instead of locking down development tools and environments, they make sure that everyone has (controlled) access to them because they know that, in these modern times, technology innovation is critical to business innovation and competitiveness. These are the enterprises that live by paradigms like:
- Continuous Integration and Continuous Delivery (CICD) [including concepts like Continuous Builds, Continuous Testing, and Continuous Deployments],
- Rapid Application Development (RAD),
- Extreme and Peer-to-Peer programming paradigms,
- Agile delivery paradigms,
In fact, except for the enterprises that are younger in age, many of those that have adopted Coding Architecture cultures were probably applying the above paradigms (and already viewed them as best practices) long before such paradigms even had labels. The attitude for these organizations being: Smart people do smart things for smart reasons… and they do these things fast and continuously!
In order to be successful in their adoption and implementations of these paradigms, these enterprises have intentionally established heavy dependencies on extreme technical skills, which are used to rapidly and continuously automate anything and everything. This includes but is not limited to:
- all aspects of their Systems Development Life Cycle (SDLC), which includes
- all aspects of dynamic Environment Provisioning and Management, and
- all aspects of Software Deployment (Builds, Packaging, Distribution, Installation, Instantiation, Configuration, Execution, etc.).
Understanding why Leaders adopt Coding Architecture Cultures for their enterprises
You’ll find the Coding Architect Culture being used and growing in enterprises that have a strong eBusiness and Digital industry presence. These enterprises see and rapidly implement tremendous amounts of change in order to stay competitive. For example, many of the largest global investment banks implement Coding Architecture Cultures. Also, the largest diet brand in the world, the largest entertainment brand in the world, and one the largest music brands in the world have established and leverage a Coding Architecture Culture. And, most Silicon Valley companies that build software also all implement Coding Architecture Cultures.
In summary, the enterprises that have a very large eBusiness/Digital presence and that live and die by rapid change are those that seem to pursue the Coding Architecture Culture the most.
The argument against Coding Architects
The people who do not believe in a Coding Architecture Culture or in Coding Architects are usually those individuals who intentionally want things to move slower or are not in a position to help make things move faster. They want extended time to capture data that can and should be captured quickly. They want time to collect data for and draw pictures for The Architecture; data and pictures that often go stale the minute they’re published due to rapid change in underlying dependencies. They want long periods of time to manually design and build solutions like the Enterprise Knowledge Repository (EKR) and the Enterprise Model, instead of using automation to facilitate much quicker delivery.
It’s interesting to note that the argument against Coding Architects almost always comes from Non-Technical Architects who either can not or do not want to perform technical functions. They argue that a Coding Architect or Coding Engineer is “less than they are” when, in fact, the Coding Architect/Engineer can do all the same things and much more. These same people usually put heavy stress on the importance of non-technical deliverables like The Architecture, communicating it as the only important deliverable an Architecture Organization should be concerned with. These are the same people who often take far longer than necessary to develop architecture artifacts because they tend not to use automation to collect, organize, and share data that is critical for architecture success. As a result, it becomes very obvious that these people are usually the first to be in danger of being perceived as picture drawers and the first to be removed when funding gets tight.
When these people argue against Coding Architecture/Engineering, it is always important to remember that a good CA/CE can do everything a non-CA/CA can do and much more, because they can (and will) roll-up their sleeves and get their hands dirty to deliver more than just “The Architecture’ and documentation.
How to build a Coding Architecture Culture
Should you and your enterprise choose to adopt and implement a coding culture, the first thing to consider is that you want your Chief Architect or Lead Architect and his or her direct reports to be extremely technical leaders who can juggle many responsibilities. We all know these people are very hard to find and expensive to acquire and keep but, when we find them, they almost always yield high positive impact on the organization. Once these people are established, they will ensure that the people who are interviewed and hired into the Architecture Organization will mirror their own abilities and traits, for example:
- highly technical,
- not afraid of technology (quickly learn and apply new ones as they go),
- move fast,
- proactively take on risk and dangerous situations,
- have high expectations of themselves and everyone around them,
- lead by example.
Another thing to consider is to force your Architecture Organization to espouse and Incubation Philosophy for shared solutions; where they are responsible for the design, building, deployment, testing, delivery, operations, and support of shared technologies, products and services that are meant to be used by more than one area of the enterprise. Doing so puts your Architects in the middle of the fire and forces them to get all connecting fires under control.
Summary and Conclusions
Competent Business and IT leaders usually know that there is far more to architecture work than just working on things like The Architecture. As a result, they expect far more from their Architecture Organizations and the architects they place in these organizations. In order to raise the probability of Enterprise Architecture success, they push hard to staff their Architecture Organizations with they types of architects who are very technical (i.e. the Coding Architect or the Engineering Architect). They expect these Coding Architects to take on complex work such as but not limited to:
- The research of new business transforming tools and technologies.
- The management and delivery of high risk projects.
- Design, build, test, deliver, operate, and even support shared technology products, services, platforms, etc.
- Design, build, test, deliver, operate, and even support shared software (e.g. enterprise libraries).
- Design and build comprehensive Enterprise Knowledge Repositories (EKRs).
- Design and build comprehensive Enterprise Models.
- (…and much more)
So, when you build your Architecture Organization, consider what culture you’ll want that organization and its architects to be the face of. You can make it an organization that just draws pictures and delivers documentation. Or, you can make it a powerful delivery organization that continuously improves business capability and drives down cost by constantly delivering real usable solutions.
In the end, it is up to you and your leadership style to decide if you want a slow moving Architecture Organization with limited technology skills or a fast moving Architecture Organization with high levels of technology skills. So, choose wisely.