Explaining how a complex technology impacts the business is one of the most difficult aspects of a Technology Architect’s job. I was chatting with an auto mechanic buddy of mine yesterday, and I explained what I did for a living. I sit in-between business executives and engineers. It’s my job to translate in both directions.
Technology architects are responsible for collecting business requirements and developing them into technical requirements. Most engineers understand the requirements gathering part of my job. It’s fairly straightforward. A new application needs to come online, and I collect the business requirements such as features, expected demand, availability, and business continuity requirements. These high-level requirements get translated into detailed system requirements, and I pass them along to an engineer for detailed designs. As an enterprise architect, I’d work in-between IT silos to ensure the overall distributed system meets the requirements across all the various platforms such as storage, compute, network and service management. It can be difficult to get all the silos on the same page as interests can conflict. The server team want virtual networks and virtual storage while the network and storage team don’t want to give up any control. But, the technology is the easy part of my job because I’m a geek.
The art of communicating up
The harder part of my job is communicating up. If an engineer comes to me and says a requirement isn’t technical feasible, or the effort is redundant then communicating up is much more difficult. An engineer’s or application developer’s time is valuable. As any architect will tell you; a component of the job will always be project management. It’s a transferable skill at this level and an expected function. As such, it’s in my best interest that these resources aren’t wasted – placing a project that’s critical to advancing the organization’s mission at risk. I’m always trying to balance my engineering resources. So, I’m especially sensitive to the pleas of engineers.
For example, an executive may read about the chance of encryption key duplication on a storage array. As a result, he might want to fast track a project to migrate to a storage array that promises to reduce the risk. It’s ridiculously unlikely that such an event would occur but the executive’s fears are real. A project like this may have storage engineers engaged in month’s worth of work when they could be working to automate processes to improve time to market. It’s my role to talk the executive down and give perspective. Delivering perspective may mean creating a PowerPoint deck that draws a picture of the true risk and explain the mitigation.
Communicating the true risk and relieving the fears is not a pure technical discussion. It’s about understanding the underlying fear such as the complete shutdown of logistics due to lost data. If logistics for a $10 billion manufacturing organization have been interrupted due to a storage issues in the past, a $5 million insurance policy in the form of a storage migration project seems a reasonable investment from a management perspective. It’s the my job to come in and have the conversation around the risks of the migration and if the project actually insures against the interruption in operations.
When it doesn’t work
I’d love to say that this is a smooth process, and I always save my engineers the pain of technically unnecessary projects. But, then I’d be lying. When technology and business intersect things get messy. Early in my career, I was forced to hire a consultant to sit in front of a console of a Novell server just in case it crashed. Talk about an expensive monitoring system. But, this showed the internal customer exactly how seriously we took their concerns.
I don’t get to install software or play with the latest hyperconverged cloudy things, but I do enjoy the challenge. Some days I walk away making everyone happy. Other days, I get to tell some unlucky engineer he has to stand in front of a Novell server just in case it crashes.