New and Notable 167: “Jon Flanders and I (Sam Gentile) were talking over dinner last night about back in the day he and I as COM programmers could keep most of our known universe in your head. Today the pace is so furious that you have to keep WCF, WF, .NET Framework, Silverlight, Atlas, BizTalk Server and many others in your head such that a Solution Architect who digests all this stuff and picks the ‘right’ way to go makes a heck of a lot of sense these days.”
(Via CodeBetter.Com.)
Saw this posted last week-ish, and wanted to put in a few cents worth of bytes.
At Compassion, several of the Sr. Software Developers (who really do have a bent towards design and architecture) have been working at a grassroots level to create a Solutions Architect role. We’ve gotten a little traction from management on it, primarily by casting it as an intra-team communication tool.
In our workplace, development is highly focused on the project. Anything that is done is funded through a project, and the project is what moves in new technology. This would be OK (sort of, but that’s another day) if there was an in-place framework, or standards, or infrastructure or something. But there isn’t. We’re trying to define strategy, infrastructure and business value all at the same time, all in the same project.
If that sounds hard, you’re right. The project is focused on time and money. As in, right now for as little as possible. But strategy, infrastructure and framework need to be able to grow, adapt and evolve. We don’t have anyone (let alone a team) that is the owner of the base level stuff. And we see the outcome of that all over the place. Each app is different; different base technology is used, typically based on the whims of either the Sr. Developer or the Architecture Office, depending on who has been to the latest marketing buzz.
We are gradually moving in the right direction. We’ve gotten the overall strategy laid down in the past couple of months. Now it’s a matter of matching appropriate technology to the strategy. For now, that’s SharePoint at the base of it all, but there are some serious questions hanging over parts of that plan.
Where does the Solution Architect come in? They are tasked to take a step back from daily development, and find the big picture that can be lost in day-to-day activities, especially as separate teams work on functionality that could be used by other groups.
It’s hard, but it’s worth it. We will wind up with a consistent framework to build in, something where the basics don’t have to be rebuilt for each project. It’s not going to be easy, but there was never a promise of that.