Todd Biske: Outside the Box

A key to any Enterprise Architecture program is solution architecture. Solution architecture is where work gets done. If your EA team is disconnected from the solution architecture effort, you’ll probably hear the term “ivory tower” a lot. Unfortunately, it’s far more common than you may think.

Looking the typical project, the first question is where do the solution architects report? Since many times they have grown out of senior development roles, odds are they don’t report into the enterprise architecture organization. On top of that, the key authority figure (decision-maker) within the project structure is typically not an Enterprise Architect, and it’s not even the solution architect’s manager. It’s the project manager and the project sponsor. This leaves a whole bunch of people that need to be influenced. They are:

• The Solution Architect
• The Solution Architect’s Manager
• The Solution Sponsor
• The Project Manager

The Solution Architect. The solution architect is going to get pulled in different ways. I believe that it is the job of Enterprise Architecture to make the solution architect’s life easier, rather than more difficult. If you’re just another voice pulling them in a different direction, it’s not a good situation. Think of yourself as a mentor to the solution architect, and provide them with the tools they need to do their job. Those tools are excellent reference material in the form of standards, guidelines, and patterns, pointers to the right people to talk to, a sounding board for options, and another set of eyes for reviewing work. On top of that, you should consider whether or not solution architects should report into the EA organization, or at least have dotted line reporting structures into EA. Which leads to…

The Solution Architect’s Manager. Assuming solution architects don’t report into EA, someone else is writing their performance review, and odds are, they’re getting judged not on the quality of their architecture but on their ability to deliver. They should be judged on both, and it’s up to the Enterprise Architecture team to work with the solution architect’s manager to ensure their performance objective include architectural objectives. If you don’t, architecture is likely to lose when push comes to shove. Also, keep in mind that you need to have regular conversations with the managers of the solution architects. Odds are they have regular conversations with their business stakeholders, who in turn influence the work that gets done. EA needs to have similar influence.

The Solution Sponsor. This is a challenging one, but very important. It’s challenging because in many organizations, IT relationships with the business are considered protected turf, and people can get really bent out of shape if you have these conversations without them there. I think we need to stop protecting these conversations and instead start encouraging them. If it can help the company deliver better solutions, then get the right people talking to each other, period. What’s really important with the sponsor is to start talking about the architecture of the effort before the funding proposal is made. If you can bring the solution architect with you, even better, because that will build rapport. Make the sponsor aware of the needs of the enterprise, work to get their support, and then when you need to make decisions within the project, the person at the top of the decision making chain should have awareness of not just the financial and schedule needs, but also the enterprise architecture needs.

The Project Manager. Finally, it’s the project manager. If you’ve properly influenced the sponsor and the solution architect, this one shouldn’t be a problem, but we shouldn’t ignore the project manager. It is their job to make sure the right things get delivered. The solution architect should be their partner in the effort, helping them to know when things are going off track from a technical perspective. There are delivery requirements, functional requirements, and architectural requirements, and the PM has to make sure all three are addressed. It is better to discuss the relative priority of each of those up front, rather than deal with the contention in the middle of the project. Will you allow the schedule to slip to maintain the right architecture? Will you sacrifice functionality for the right architecture? Talk about this before it becomes an issue. Also, if you have a formal review process, make sure the PM knows what is needed and what questions are going to be asked. They want the review to go smoothly, so you have to give them the tools they need to know when they’re ready to be reviewed and to pass without any issues.

Hopefully you’ve found this focus on solution architecture useful. As topics come up under this theme of architecture by influence, I’ll have additional posts. If there are specific questions or challenges you have, feel free to send me an email or post it via a comment.

3 Responses to “Architecture by Influence: Solution Architecture”