4

The project I am putted in is running awful. :-) Main Problem is a missing architecture and a missing guidline how to organize projects. In this case I have done a sample project architecture with UML class and component diagrams and layer diagrams. The main problem is, that I have to present this architecture to the management. But the management is not familiar with UML or Layer Diagrams and for most of them its not possible to understand the logic behind it.

In that case I want to present the management a visualized project structure with easy understanding. I've searched for some ressources and examples with easy understanding visualizations, but was not able to find one.

So my question is how you would visualize your software architecture to the management, which techniques do you use?

Little Note: its a very big sharepoint project with more than 50 sub projects.

Improve this question
2
  • 1
    Pen & paper. Honestly ;)
    – yannis
    Mar 13, 2012 at 13:40
  • I dont know this old stuff ^^
    – Smokefoot
    Mar 13, 2012 at 14:08

2 Answers 2

Reset to default
3

UML is a great way to communicate design to technical resources on a project, though in my experience, the vast majority of non-technical project resources get lost with it. UML does indeed require a minimal level of training to fully understand it or formulate it. Some non-technical peers may be experts in Use Case diagrams lets say, but when they see a component diagram it might as well be written in kanji.

I find that knowing your audience for the diagram is important before you start drawing. Non-technical peers generally have an easier time understanding and following Flowchart diagrams rather than Activity or Sequence diagrams. They may also just want labeled boxes and arrows instead of a full UML component diagram or deployment diagram. Sometimes I will do two sets of documents, one simplified for non-technical peers and one in UML for technical peers. Other times if I am running short on time I don't even bother with the UML diagrams because most of the time the technical person can generally understand the complexities in the simplified diagram anyway.

Another important question you have to ask yourself is why your non-technical manager finds these documents important? Is it because the project is running into problems and the urge to micro-manage is setting in? Is it to assist a quasi-technical sales person in better explaining the advantages of your software and architecture to prospective clients? It could be as shallow as a manager wanting to pin up complicated looking diagrams in his office or technical area to try and impress visitors he brings to the office (true story). The bottom line is to know your audience and know it well.

Improve this answer
2
  • For sure you are right. For a non technical the understanding of UML or something like that is some how impossible ;-) But in some business its neccessary to tell the management how it should look like. I have now done a small approch with a onion layer diagram. I wanted first to show the management how it could look like and how each layer is in the relation with other layers. I hope this would work ;-) But in further steps a very good technique would be nice :-)
    – Smokefoot
    Mar 13, 2012 at 13:16
  • 1
    UML component diagrams actually can be used to communicate an architecture to non-technical people. My general experience is that people get confused about interfaces and connectors. If you omit these (which is valid UML) you can produce an architecture overview which decomposes components into sub-components (systems into applications, applications into modules,...) This is an abstraction most people easily understand. It is similar to the informal boxes-and-lines architecture description style. And it can be easily mapped to project management work breakdown structures.
    – Bernd
    Mar 13, 2012 at 19:20
1

Main Problem is a missing architecture

What problem does your architecture solve? Even the most poorly designed application has an architecture, so unless you're starting from scratch, one exists. In your case, maybe no one bothered to document it. Management wants to know that you have one that gives the project some sort of advantage (e.g. performance, ease of maintenance, code reuse, accepted standards, etc.).

missing guidline how to organize projects.

They'll feel more comfortable if you don't appear to be working in chaos. Prioritize the 50 sub projects. Designate someone who is tracking the progress. Show them you have a system, so you know developers are getting things done. Can you show the architecture is conducive to this type of project?

Unfortunately, they really want to know: How Long? and How Much? You should be able to answer these questions, but it may not be as accurate as they want.

Improve this answer
1
  • In this point, for this project, i have to disagree. There is a architecture for sure, but its bad. Changes to one subproject depends all the other projects as well. The project is destroying it self. My management needs advise how to do it better. For sure costs and so one are important parts too, but in this case they want to know and understand my point of view. In this point of project I can only try to save some parts, I would never do a refactoring (its to big and mostly finished). But its for upcomming projects.
    – Smokefoot
    Mar 13, 2012 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.