11

We are looking at improving the process for handing over tasks from architecture to development.

At one end of the scale it there is no architecture guidance you risk getting chaos, with each developer doing things his way.

At the other end of the scale where everything is specified, the specification takes longer than the development, and you risk having very boring development tasks.

Has anyone found an optimal middle ground between these extremes? Which artifacts do you deliver to development? For example: modules, class structure, or sequence diagrams?

Bill the Lizard
  • 8,408
Shiraz Bhaiji
  • 527
  • 3
  • 12
  • 14
    I read a comment here somewhere that said architecture is a team sport. If you're handing over from the architects to the development team, you're probably doing it wrong. – Ant Dec 07 '11 at 09:16
  • @Ant, I agree in principal. A complete handover and then walking away is definitely doing it wrong. Handing a design over, and then working with developers to refine the design and guide the process, while leaving the details to the developers, and staying with a project to the end is doing it better. This is why you'll never truly see a successful software project where a design team was contracted in and then asked to leave once the specification documents were "completed". – S.Robins Dec 07 '11 at 14:57
  • 1
    At one place I worked, handover was essentially accomplished by providing Development with a mostly implemented prototype that generally worked and would under no circumstances scale. However, you said you wanted to improve your process, not make it worse. – David Thornley Dec 07 '11 at 19:20
  • 2
    @DavidThornley I was at a company that had an architecture group that did that. They would sit around and stroke their gray beards, postulating ridiculous ideas that are full of holes and logical dead-ends. They would then whip up a poorly implemented prototype that only vaguely demonstrates their mental masturbation. It would then get handed off to a development team so they could "implement" it, but the development team would quickly realize that the idea ignored several mostly insurmountable problems, causing the project to fail. Architects took no responsibility for failures of course. – maple_shaft Dec 07 '11 at 20:26
  • In large shops (and according to TOGAF standards) there are several distinct architecture disciplines: Enterprise, Security, Infrastructure, Solution etc. etc. Using the term Architect or architecture on its own is meaningless. The question appears to be about "Solution Architecture" and the answer is that the Solution Architect should be an integral member of the development team. – James Anderson Dec 08 '11 at 01:51

7 Answers7

17

I will start out by saying that the very concept of a seperate "Architecture" team is an affront to good software development practices. Architecture teams in corporate environments tend to be a culmination of the worst ivory-tower pseudo-intellectual bull** artists that can be found amongst the pool of developers.

Other organizations treat Architecture groups like a political reward and justification for a massive salary to the most senior members regardless of merit, knowledge or skill. Most consist of both types.

Every developer can and should be an architect and should be involved in the high level designs of a company. The very thought that a single group has complete dictatorial control over every aspect of software design and that must be handed off to developers who didn't contribute to the design, don't understand the reasoning behind the design choices, and may understand critical flaws in the design being more comfortable and closer to the actual implementation and existing code, is frankly completely flawed from its very core, and will consistently result in one of three scenarios:

  • Developers do not comprehend the design, or outright reject it due the realities of the current implementation, and end up determining their own undocumented design and implementing that instead. The situation is formal design documents that do not reflect the implementation of the software.

  • The developers blindly follow the design that may or may not take current requirements or unique aspects of user stories into consideration, resulting in a buggy and poor quality implementation.

  • Intelligent developers who understand the design documents, and are able to implement them, quickly get bored with not being involved in design discussions. They are either likely excluded from participating in the Architecture group due to political or seniority issues, so they become frustrated, bored, and leave for greener pastures. This negatively affects the project resulting in a brain drain causing the vicious cycle of poor software quality to continue.

The single best way to mitigate this problem is CHANGE the Architecture group and possibly put them in tech lead positions. The role of the Architecture group should be more or less a "scrum of tech leads" if you will. They should only rarely meet and only discuss the highest level technical direction issues, Eg. think discussion migrating from Java to Scala, Abandoning Oracle for MySQL, possibly writing common utility libraries that mandate a certain TYPE of design process over another, switching from StarUML to Altova UML.

Actual and real software design will be a community process involving ALL software developers, laid out by the extremely high level direction of the Architecture group.

maple_shaft
  • 26,511
  • 11
  • 57
  • 132
  • OP's question was about how much to communicate. Just changing companies to remove their architects doesn't address this, and is likely to meet with stiff opposition. Change is hard, even when necessary, and always meets resistance. The key then is to begin with addressing problems with communication, and take things from there. Speaking from long and sometimes painful experience, changing how teams work requires a large effort in terms of cultural change, and that requires very subtle and patient "refactoring" of business processes and thinking, great sensitivity, and ultimately time. – S.Robins Dec 07 '11 at 14:50
  • 5
    @S.Robins With all due respect, the OP's question was how to solve the problem (all questions on this site are about how to solve a problem). Changing the team structure is the only true way solve the problem. Other suggestions are great, but they are just band-aids. They do not help in the long term. – maple_shaft Dec 07 '11 at 16:02
  • 2
    +1: I have worked at two companies with a separate team of architects, and one with a CTO who insisted on making all architectural decisions but had no delivery responsibility. All three had devolved just as you describe. None could retain strong developers; the "Dead Sea" effect was pronounced. Projects were completed, but at extremely high cost. – kevin cline Dec 07 '11 at 17:45
2

There have always been problems in how information is flowed from architecture to development test and operations. The way to tackle these problems imho depend on several factors like:

  • size of the software
  • complexity
  • culture in your organization
  • belief.

For certain combinations of these factors a pure agile approach cross-functional teams with emergent design is appropriate. The information flows by working together. The disciplines document what they need.

For other combinations of these factors a small team of architect,tester,operations expert and lead developers might start with architecture iterations slowly building up the architecture, documenting and getting immediate feedback on their architecture decisions. Slowly more developers that implement features can be added to the team and the original core team can be made smaller.

Mostly for government and finance projects it is required that more documentation is written upfront and that can take a long time with no real world feedback on your choices. In my mind the biggest reason that many of these projects fail. Still if this is your situation I would make the documentation to fit the requirements And than use option 1 or 2 to actually build the software and refine/adapt the documentation.

Hope this helps.

KeesDijk
  • 8,948
2

I know this will not be very popular but the comment you made

At the other end of the scale if everything is specified, the specification takes longer than the development. And you risk having very boring development tasks.

is actually something you should strive for. If the design and specification is solid enough that the development tasks are boring, then the cost of development goes down. It is much less expensive to fix a specification than it is to fix code, and the biggest cost of software projects is not the build, it is the long term support. And supporting code that is based on a solid spec is much less expensive.

Jere
  • 21
  • 3
    The best spec in the world is completely useless if the implementation does not reflect it. This is what happens when design specifications are done by people who are not involved in implementation. – maple_shaft Dec 07 '11 at 20:18
  • 1
    This is very true. The trick, however is finding the right balance. – Michael Dec 08 '11 at 13:58
  • Your statement is true in some worlds. In many other worlds, the biggest cost of software projects is the business opportunity cost of every day that the product is not shipped. Delaying the launch of a company, for example, can kill the window of opportunity it is trying to exploit. Of course, shipping a piece of crap can be just as fatal. But front-loading the work into spec design is really heading down a slope to late, buggy projects that nobody likes, including the developers. – Bill Gribble Feb 02 '12 at 16:53
1

I don't entirely agree with maple_shaft's answer, but there wasn't enough room in the comment to say my entire bit! ;-)

I agree that every developer can and should be an architect, but that does not mean that every developer should be responsible for the architecture of an entire product or system. Further, I don't think you can paint every architectural team with the same broad brush, and when done right architectural teams can deliver great value to the overall product development process. The misconception is that the architects should dictate every aspect of the system design. They should instead focus on the higher level design, and leave the implementation details to their development teams. That isn't to say however that the developers shouldn't be involved in the planning and design process from the outset.

The larger and more modular and ultimately more complex a product is, the more likely you will find various parts of the product handled by different development teams. Such teams need not understand the system as a whole provided they have a full understanding of the parts of the system that they are responsible for. Often these additional teams are brought on as subcontractors for the specific purpose of developing a module in a particular area of technology that the architects or other teams may not have expertise in. My own particular talents lie in developing API's, and I have yet to see a well factored API that was developed entirely organically without either being a complete mess in terms of usability, or that did not require someone to stand out as the person who ensured there was a level of uniformity between different aspects of the API. I can go on to list many examples and reasons, but I don't think that these sort of situations are the ivory tower BS that many might think they are. Unfortunately, there are many places, particularly in areas of defense, medical, and the financial sectors where corporate paranoia does result in poorly specified and even more poorly managed product development of the sort that I'm sure maple_shaft was most concerned about. These are the things that I believe give architects a bit of a poorly deserved bad name (generally speaking).

So where is the middle ground that the OP was looking for? The answer is all to do with opening channels of communication. The architects need to hand over specifications that describe their designs in enough detail so as to ensure the development teams will understand where the boundaries are. Stories and Feature Scenarios in the broadest sense, where everything is considered a black-box. The architects then need to ensure that the teams have access to the architect's time to confirm any assumptions, and to have any questions answered about specifications that seem too broad, or unclear. After that, it's really about ensuring that individual teams are made aware of what the other teams are working on, and that they know who to liaise with on the other teams to ensure each part of the system will play nicely with the other parts. These teams meet each other directly. Once the system has been designed at the broadest level, the architects should really just be the people the teams turn to when they need a sanity check, and to ensure that the product "vision" is maintained. They should also take on board any integration process required, and provide much needed "air-cover" for the development teams from the managers, customers, and any other stake holders, while still ensuring these various people can all get together to work out between them how things should work.

IMHO architects should first and foremost be facilitators & communicators, and designers second. As to what level of specification? I think that the best architects are the ones who ask their teams about the level of detail that a team wants, and between them find a balance that works. Different teams may have different requirements in terms of the amount of documentation or direction required. Senior teams may find a roughly drawn diagram and a quick chat may be enough to get going with, while teams filled with relatively junior developers may require a little more to get them going. Above all, the architect needs to encourage developers to exercise their own design talents in order to get the best end result from each team.

S.Robins
  • 11,485
  • 3
  • 37
  • 52
  • +1 and 1000 more if I could! You more eloquently elaborated on my answer. I especially love this quote, architects should first and foremost be facilitators & communicators, and designers second. This is essentially what I am saying in my answer. The fact that architects are delivering design specs to the developers is fundamentally wrong and goes against how an architect brings value to an organization. This is why I was mandating rather harshly in my answer that a team reorganization is the only answer. – maple_shaft Dec 07 '11 at 16:11
1

Since you strive to improve something, then you have already sensed a problem in your process. The root cause for the specific situation might be the following: The developers cannot identify themselves with the architecture, because it was imposed on them by someone external. Handing over the architecture to the development will very likely not solve this root cause.

Make the architecture a part of the development team. Tear down the border between the architect and the developer. This ensures that the information will flow. If the development team participates at shaping the architecture they will not regard it as something alien. Infuse knowledge about architecture into the team. Teach them the driving factors behind the corporate architecture to avoid the chaos you mentioned. Involve developers when architectural decisions must be made to avoid the boredom you mentioned. A handover is then not required anymore and you have fulfilled your role as an architect in a development team.

Theo Lenndorff
  • 2,544
0

You need to give as much information as possible for the future team to maintain the code. If you do not have sequence diagrams for example, the developer is forced to trace the code step by step, thereby wasting time.

Also there is room for the new team making assumptions that are invalid.

In general there should be a document about what the project is , the technical specifications, unit test cases and sequence/class diagrams.

Vinoth Kumar C M
  • 15,565
-1

I would say that Class diagrams views creating a model as well as code is a solution. The class diagram represent the static view of your project architecture. I mean that you have packages > classes, intefaces, enum > attributes, mehtods etc... > etc.. If you look well the UML2 metamodel has exactly the same structure as a java or dotnet project.

What we use in our projects are simply class diagrams which are saved into a single model. We generate views of the model if the classifier already exists or create new one at graphical if it is new. Developers can see our diagrams and model because saved at the project folder root inside CVS. What I like is that also the developer can model because if something is changed at code level then the model is automatically updated on CVS for the entire team.

It works really well and no real need to know UML because class diagram is really simple and reverse engineering will do the job and create the graphical view of the code. Simple navigation, advanced and detailed views where plenty of comments could be added with diagrams always up to date and visible on CVS directly in the project. My UML class diagram is now Magic :-)

maple_shaft
  • 26,511
  • 11
  • 57
  • 132
UML_GURU
  • 258