So, you think you know how to build software? Great! But do you know what software to build? Knowing what to build and what not to build takes more than technical knowledge and is what Enterprise Architects do. In my long career in software, here are some of the things I’ve learned as an Enterprise Architect.
- Decide on a technology to fit your team, not just the problem. When you’ve worked in the software industry long enough you tend to lose the youthful idealism that once sparked long debates over which technology stack is better than another. It’s been quite a while since I’ve had a heated argument over whether Java is better than .Net (of course it isn’t). As a solutions architect you tend to look at how to apply the right (or newest, or coolest) technology to a problem. But as an Enterprise Architect you often have to apply the right technology to your team. For example, if you need to build a mobile app for iOS few would argue that Objective-C or Swift would be the best technological fit for performance and access to native features. But what if your team is C# developers? You’d likely choose to develop the app in Xamarin. Or perhaps they have web experience so you might pick Apache Cordova. Trying to force a technology shift on your team will incur learning curve delays and most likely reduced quality as they create their very first app in a new stack.
- Build on your strategy. One aspect of being an Enterprise Architect that borders as much on voodoo as experience is creating a technical strategy for your organization. This involves everything from evaluating the future needs of your customers to trying to decide which technology wave to ride and which to let pass by. Once you land on a strategy, the architectural decisions you make afterwards are often driven by that decision. Pragmatic solutions that fit the needs of a single system must sometimes yield to the higher level strategy which is a fact that I can say from personal experience is a very efficient way to upset a solutions architect. One example from my recent history is pushing to move all of our apps to use an open source claims based security token service. Most apps already had their own security but to enact the Single Sign-on strategy those apps had to adopt the new model.
- Know when to push and when not to. As an Enterprise Architect you are constantly balancing your strategy with commercial realities of being a for profit organization. It’s sometimes difficult to let your long term strategy suffer to enable a short term commercial goal to be met. However, never bowing to commercial pressure means you run the risk of losing important market opportunities that could be valuable to the organization. Bowing to commercial pressures too often means your technical strategy is never implemented. Keeping your wits, and your sense of humor, in this tightrope act is what makes you a successful Enterprise Architect.
- Don’t build software you don’t sell. Even if you work in an organization building software for internal use you should always consider the question “Would our customer buy this?” If the answer is no, then you probably shouldn’t be building it. Many times I’ve seen teams build tools and utilities that find their way into the hands of the customers only to realize that now they have to support and maintain them. Leverage existing software as much as you can or that makes sense commercially and keep your teams focused on your strategy and your customer.
Of course this isn’t to say that being an Enterprise Architect is necessarily better than being a Solution Architect. There’s certainly enough work to go around and often you may find yourself wearing both hats at the same time. But having the ability to look beyond the scope of a single solution to how to leverage technology for your entire enterprise is what sets Enterprise Architects apart.