How To Align Architecture With Organizational Goals: A Process for Technical Architects Pt 2

With Nigel Kerr

ITHAKA is an edtech nonprofit that makes materials for higher education and academic research more accessible online.

With Nigel Kerr

Continued from part 1…

Nigel Kerr is Chief Architect at ITHAKA, an edtech nonprofit organization that aims to make higher education materials more accessible to the broader public and prioritize inclusion in educational opportunities. His job is to align the technical architecture for a product that digitizes and makes available scholarly journals, art collections, and other educational materials to ITHAKA’s organizational goals in a way that enables the people of ITHAKA to keep making an impact. How can similar software development professionals align architecture and business outcomes? What process or considerations go into this important role? Nigel sat down to share his approach and perspective….

Today we are covering the details and considerations when aligning architecture with business goals. If you’re going through a similar process at your organization, we hope this is helpful to you.

Technical Architecture at the Micro Level

Q: Nigel, once an organization has outlined their technical architecture plan and aligned their mission and resources with macro business goals, how do they flesh out the details?

A: It’s important to keep high-level priorities in mind and then apply that to individual scenarios at a micro level. If there is a project we need to do, I ask questions along the line of:

• What is the outcome we need in this setting?
• How does that align to our macro goals?
• Can we get that outcome the way we intend to have it?
• Are there other ways to do it?
• Are any of them better?
• Are they fast/reliable enough for customer expectations?
• Is this sustainable?
• Is this affordable to run?

Q: It sounds like you’re reality-testing your goals and balancing that with the resources available.

A: If I ask someone, “Can we afford to operate this?” that affordability only makes sense in the context of the business/money/time the organization can bring to bear. We’re not at Google, we’re not at a 1-person start-up either; the context means something different at another business than it does here. I have to communicate that context to all the people doing the work, constantly.

Q: Tell us a story about what it looks like when these practices are in play and things go right.

A: An example from the last few quarters: our new Shared Collections service provides ways for libraries to upload and publish their own digitized collections onto JSTOR, so that they can be discovered and used there. Some library customers do the uploading and publishing themselves with provided tools, others have ITHAKA upload and publish for them.

Uploading and publishing are necessary to get the benefit of the program, and we have had growing pains with those processes and applications. We did not always know whether or when an item upload or publish process fully succeeded or encountered a problem; when we didn’t know, we certainly couldn’t inform the customer or internal staff what happened. Sometimes our knowledge and messaging around success or failure lagged, or was unhelpful.

The outcome we want is for customers and internal staff to have a trouble-free and fast experience uploading and publishing, so that their valuable collections get on JSTOR quickly. If there is trouble with a given item or collection, we want that customer to know in a timely fashion that there was a problem, and ideally what they need to do to make progress. Our technology and systems didn’t give those outcomes yet.

Together with the teams involved, I asked, “What information do we need from our systems to start supporting those outcomes? What sets us up to deliver those outcomes better and better?” The fundamental issue we arrived at was getting accurate and timely data about success and failure. If we had that, we could start using that information to inform customers better, and use the aggregate success/fail information to make decisions about what needed attention next.

That led to work out: “How can we collect event data from several applications across a few teams about items as they move through the system? How can we use that event data quickly enough to inform the customer? What technical details allow us to do this best?”

After getting these data about success and failure flowing, this was a new metric to watch and understand. Deviations from expectation would appear, and we learned to look into those deviations efficiently. A drop in success meant we weren’t delivering on the desired outcome, and we all knew that we were organized better to deliver.

Q: So what does running through this process look like at the technical level in a specific situation?

A: I ask myself:

• How does this team/person/group contribute up to alignment to the macro goals?
• Does this team/person/group have what they need to make progress?
• Do we need to amend how we’re going about it and with whom we’re going about it?
• What resources do we have at our disposal?
• Are we having the impact we want to have?
• We have a team earnestly working on this thing. Is it going well?
• If it’s not going well, do we need to adjust?

As if that wasn’t enough, there are always constraints on any project, including legacy concerns. These constraints will also exert force on what you can do, want to do, and can afford to do.

Considerations When Aligning Architecture to Organizational Goals

Q: Technology is always changing and is accelerating rapidly in some areas. With so many variables to bring together, and frequently large investments of time and money, how do you prioritize competing demands? Is there a singular touchstone or north star you have found useful to keep ITHAKA moving forward?

A: I’m almost always thinking about speed and getting traction. Not everything proceeds as quickly as we would like. A team might not be able to use the right tools, or the thing we chose is slowing us down, or we keep getting interrupted by high-priority issues. There could be any number of reasons why we are not able to get the value and outcome realized as quickly as we’d like. These are things all organizations and teams experience.

Aligning architecture with business goals comes down to a matter of joining what’s working now with what looks like it will work going forward in that context:

• using the right tools
• teamwork
• understanding priorities that might conflict
• technology that helps or hinders speed or effectiveness
• empowering teams to succeed independently but aligning their goals

To make the best progress at the right time, choices and teams and efforts might need to adjust as we go. That’s fine, and let’s make sure the outcome still aligns.

Q: This sounds like a complex iterative process that is ongoing and requires constant rebalancing.

A: Yes! I’ve made this sound much simpler and easier than it is. I’m still learning how to best manage my time between all the contacts, help in specific areas of the technology, encourage learning and experimentation, and apply our business goals to how we technologists work. Changes to business and technology are recognized and won with messy thought and effort over time. I certainly don’t have all the answers, but I do have a broad and deep collegium here at ITHAKA to work and learn with to seek the ideas and plans we can use. Pursuing our mission is very rewarding, and I’m lucky and grateful to be one part of this organization.

Suggested Reading on Adaptive Strategy

If you’re interested in learning more about adaptive strategy, Nigel recommends the following reading:

• Good Strategy Bad Strategy: The Difference and Why It Matters, Richard Rumelt.
• Lead Through Volatility With Adaptive Strategy, Jackie Wiles.
• Inspired and Empowered, and articles from SVPG: Missionaries vs. Mercenaries, Empowered Engineers FAQ
• Porter’s Five Forces Analysis

Interested in exploring careers and Ann Arbor jobs or New York jobs with ITHAKA? Check out our ITHAKA jobs page to learn more and speak with recruiting.