The missing relationship between Enterprise Architecture and Procurement

Isn't it fascinating how procurement departments negotiate enterprise agreements without an understanding of the roadmaps or even the unarticulated strategic direction that enterprise architecture team wants to drive towards...



Many software license agreements are not a fit for their intended purpose. Many contracts fail to explain clearly what the buyer has to measure to stay compliant, place unreasonable restrictions on usage and/or deployment and of course can be an impediment to the enterprise taking advantage of cloud computing.

When these two groups aren't communicating, it is guaranteed that this will result in unexpected software costs and audit costs. The communication however doesn't end here as it is important for the vendor to also participate in the conversations. Generally speaking, many enterprise architects ask thoughtful questions of vendors but fail to get how specific scenarios should be handled in writing. Lawyers that work with procurement teams are very good at getting in writing what was agreed if you can explain it clearly with relevant examples. Oral descriptions of policy and promises that "we never enforce that" are insufficient.

Another missed opportunity is for the enterprise architecture team to periodically recheck existing license agreements to see where they may need to be amended. Generally speaking, much of the license renewal ceremony revolves around keeping down costs, but this isn't an excuse to also ask for several new considerations. After all, you are much smarter now than you were when the agreement was negotiated. If the enterprise architecture team isn't providing input, then this is criminal...

Ten Interview Questions for Enterprise Architects

Want to find top talent? More importantly, want to know the types of questions I would ask if you had to interview with me? Below are ten questions you should ask of enterprise architect candidates as part of the interview process...



I have decided to make this a two-part blog where the first part is simply to present the questions with a followup as to the importance of them.

1. What type of work do you want to be doing five years from now?
2. Do you think that if the Federal Government had top talent in its enterprise architecture team, would the deficit be lower than it is today?
3. What does work/life balance mean to you?
4. Do you write code outside of work?
5. What was the best and worst software project that you've been part of?
6. What was the defining characteristic of the best and worst boss you have worked for?
7. What would you recommend in terms of enterprise spend for security. Would you target more money for infrastructure or for applications?
8. How should enterprise architects be involved in the pursuit IT outsourcing?
9. What value proposition could cloud computing provide to our organization?
10. Are you on LinkedIn? If so, do you participate in a larger enterprise architecture community?

Enterprise Architecture: The Era of Silence

It would seem to me that if Enterprise Architects wanted to improve the quality of enterprise application development, they would beat their PMO silly with wet noodles for designing processes that allow for the era of silence...



Increasing, many enterprises are convincing themselves that they adhere to Agile methodologies, yet somehow they have simply hijacked the vocabulary of SCRUM and are still waterfall in their approaches. Even for enterprises that are honest enough with themselves and have acknowledged that they can't be anything but waterfall still need to take the next step forward and acknowledge the existence of the era of silence.

The era of silence is the extended period of time, often measured in six to twelve month increments squeezed in somewhere between completing the analysis of user requirements and the big bang testing phase. The era of silence is only broken when discussions betwen development and the customer occurs on the predictable status of the development schedule.

We all know that an enterprise and their PMO organizations love process, but how come we are solely focused on process steps and governance gates at the expense of building better software? Wouldn't it be wonderful if a PMO didn't focus on what artifacts we produced on what dates vs focusing instead on ensuring that large expanses of time don't occur without everyone involved in the SDLC truly collaborating...