Rob Windsor on WCF with REST, JSON and RSS
WCF is not just for SOAP based services and can be used with popular protocols like RSS, REST and JSON. Join Rob Windsor as he introduces WCF 3.5 and its new native support for non-SOAP services.
News
Ted Neward's thoughts on Architecture Roles & Responsibilites
Posted by Gavin Terrill on Sep 24, 2007 12:30 PM
Ted Neward recently provided some insights into what the roles and responsibilities of an Architect are, in response to some hard questions about Architects.The first question was in relation to "what does an architect do"?
For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them.The next question asks if architecture should be facilitative or restrictive:
Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation".Finally, the email asks if architects are still relevant:
But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed.
Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.These sentiments echo those of Fred Brooks, author of The Mythical Man Month, who sees the Architect role as a critical enabler of "Conceptual Integrity":
Conceptual Integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity...after teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager, and a separate architect.What are your thoughts on the roles and responsibilities of Architects?
RelatedVendorContent
The Agile Business Analyst: Skills and Techniques needed for Agile
Rainmaking - IBM's software virtualization strategy (Jerry Cuomo CTO blog)
Hibernate without Database Bottlenecks
Memory Analysis Best Practices Within Eclipse
Introducing application infrastructure virtualization and WebSphere Virtual Enterprise
-
Fowler talks about architecture being irrelevant in an agile project
Maybe he has said that somewhere that I'm not aware of, but I'm pretty sure he has an article on his site that describes the role of an agile architect in terms remarkably similar to those employed by Neward (I would confirm that but Fowler's site seems to be down at the moment! Perhaps he should hire an architect...).He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
On the agile projects I've worked on all of this is included in the role of "Developer". Successful agile projects rely on every developer doing these things, not leaving it all up to one architect. Where the architect does make a distinctive contribution is by providing technical requirements for the system. Kind of like a technical customer as distinct from the business customer. For instance, in an enterprise this technical customer needs to be identifying reusable services that can be developed not only to benefit the current project but others as well, and requesting the factoring out of these services as storycards in the project. They also make more of the macro, pre-development decisions like build-from-scratch or buy-and-integrate. Then, as the technical customer, they accept the system from a technical perspective (which implies they understand down to the low-level, as Neward says) and help the developers achieve the desired result when they need help to do so. The role presented by Neward seems to me more like a Master Developer, which would be necessary if none of the developers are masters, but not necessary if at least some of them are. -
On the agile projects I've worked on all of this is included in the role of "Developer". Successful agile projects rely on every developer doing these things, not leaving it all up to one architect.
While the devs will certainly determine what I'd call local architecture on small projects or portions of larger projects, you still need someone connected to the bigger picture, connected to activities in other groups if they exist, or connected to knowing what is coming in the future to help provide context for the devs' decisions. While agile is often concerned with technical debt and YAGNI, I personally believe some guys take this too far and generate unnecessary rework and wasted time for themselves by ignoring inevitabilities because they aren't relevant in the current iteration. Knowing when developing something is technical debt and when it is actually effecient IMO is a place where the architect or master developer should be managing. If a CEO is supposed to be providing the larger vision for the direction of a business, the architect's role is supposed to be providing the larger vision for the technical aspects and direction for the dev team as a whole. If the project and team are small enough, then consensus among experienced players is certainly suitable. When there's bigger groups, someone has to be laying the basic ground rules and connection points. My guess is some people have a semantic problem with the term because of its connection to pre-planned engineering that agile is counter to. Clearly you can't have 100 people split up in to a bunch of teams doing whatever they want -- there has to be coordination. Call him an architect, a master developer, the jerk boss or whatever you want, but he's necessary (and hopefully agile orgs are better at picking a good guy for that job than most companies). -
If you're doing a project in rails you probably don't need an architect. However, you may wish you had a capable architect in case your project involves any of the following: remote access, web services, serialization, copy-by-value, asynchronous execution, threading, messaging, (distributed, ...) transactions, OR mappers (many potential issues), sub-components, packaging, complicated dependecies, potential software quality issues, complicated domain model, VPD, ...
-
I wrote a blog entry a few months back about what type of architects there are out there. It seems the confusion and lack of clear definition continues. If you wouldn't mind, could you shoot a comment over onto my site in regards to by entry? My entry is available here.
-
The views presented to this point fail to emphasize the levels of work at play in the enterprise. Since when does an Architect lay bricks? Is not architecture design? The function of the Enterprise Architecture team is is pointedly to effect Enterprise Architecture. It is clearly a governance function. This includes as a necessary element facilitation and high-level control of individual solution architectures. In 'point' or Line of Business solutions the term 'Solution Designer' clarifies the controlling aspect with regard to focus on the integrity and suitability of a solution, as provided by an in-team resource. The goal is to align with and fill the requirements of the controlling Enterprise Architecture team. The term 'Systems Analyst' could describe the implementation-focused solution accountability role described in this thread. This could of course be delegated, shared and/or rotated. Agile teams can and do excel in such environments in which the bigger picture is the domain of persons beyond the team boundary. I agree that in smaller, isolated projects with mature teams there certainly seems to be no need for 'Architects', perhaps excluding the need of some to wear eppaulettes.
-
I've been working with selenium since last year and it´s great for web test. It´s true that ajax have been a problem for selenium but the extensibility allows anything. The posibility of implemet new commands have allowed me, and my company, to solve the problems implementing personalized comands. Selenium: It works... and if it doesn´t you could make it work! Thanks from:
Las Vegas Entertainment
Stress Management
Best Web Hosting
-
Thanks for article
Bedük
7 comments
Reply