Getty Images
4 enterprise architect skills you should never overlook
While there's certainly plenty that goes into being an enterprise architect, what skills are the absolute 'must haves' to stay on top of the job? We examine a few.
At its peak in the early 1970s, the IBM System/360 project had over 250 software designers and engineers working full time on the mainframe's underlying software. At the time, the sheer size and scope of the mainframe systems involved made System/360 one of the largest and most sophisticated software initiatives to date.
With so many components, personnel and individual contributions to manage, a project like System/360 required a type of team member that could work at a managerial level while also focusing on technical details and end-user needs. Eventually, this gave rise to what the acclaimed computer scientist Fred Brooks would christen the software architect role. As foretold, these architects became responsible for a gamut of tasks that tread definitively into the business side of organizations as much as the technology side.
In this article, we'll focus on the role enterprise architects play in software system maintenance, enterprise application design, development team management and communication with the business side. More importantly, we'll review the specific enterprise architect skills that are critical to both possess and regularly sharpen, as well as techniques that can help improve those skills.
Emerging software architecture patterns
In addition to new development methodologies, programming languages and the like, enterprise architects should take particular care to stay on top of emerging software architecture design patterns.
For instance, enterprise architects who understand the exact differences between event-driven and enterprise service bus design patterns can add a great deal of value to organizations attempting to migrate away from a monolith. As for the code itself, architects could also consider taking up part-time programming work that allows them to practice implementing those patterns on a smaller scale.
Staying up to date with certifications
Architects generally need to stay on top of both platform-specific and practical certifications in order to stay relevant in the field. Platform-specific certifications, such as AWS Cloud Solutions Architect and Red Hat Certified Architect, will help an architect demonstrate their ability to readily work within a specific technology stack. Certifications like The Open Group Architecture Framework (TOGAF) and Axelos ITIL Master Certification, meanwhile, demonstrate an understanding of fundamental architecture modeling and business communication concepts as it relates to the enterprise.
When choosing a certification to pursue, it's important to consider the specific value to your organization (or what companies that are hiring for a certain certification). That research should give you ideas about the certifications that best align with your career aspirations.
Keeping a foot in the business side
It might not be ridiculous for an enterprise architect to consider getting an MBA degree as a way to serve the business side. Another option is to read the source material itself, such as Peter Drucker's The Practice of Management, or Michael Porter's Competitive Strategy, that covers the architecture of business.
You could also look to groups like the Business Architecture Guild, an educational group committed to helping software professionals create architectural blueprints that align business strategy with operations in a practical manner. Another place to look is within your own company. Ask a marketing executive what their favorite book on marketing is. Do the same for colleagues in accounting and finance -- these questions might prompt interesting business conversations.
Honing communication and collaboration skills
Enterprise architects should aim to excel at communication and collaboration. For example, say a graphic designer and programmers disagree about who owns a design. The first step is to understand what each party is talking about and how to interpret the issue. After discussing the concerns of both parties, it might be apparent that the graphic designer was talking about owning the front-end design, while the programmers were mostly concerned about the structure of the code.
Such a dispute can seem silly but too-often go unresolved until someone with strong leadership skills steps in and really listens. It is also important to stay organized and write down where and when an issued occurred or a conversation happened (including what was said and what happened as a result). The same applies to one-time communications like instant messenger, email, phone calls and text messages. No matter your role, you'll add value to almost any organization if you take the initiative to write down all the places the information is stored (and for what purpose).
A proficiency with formalized architecture roadmaps
A data architect once said to me that the job of an architect is "draw boxes and fill them in." There is some truth to that -- if those drawings add value and truly clarify what the organization's software architecture does.
On that front, architects should become readily comfortable with things like TOGAF and the Zachman Framework. These types of organizational roadmaps are more than just lists of where things are; it communicates where things must go.
Try creating your own enterprise roadmap to get comfortable with it. You can start by reworking a small team's existing product roadmap, something no more than four or five pages long. If other team members start studying and talking about it as a source of truth, then you have something to refer to as a proof of work of architecture.
