This Week Let’s Discuss Architecture With Respect:-

To the models required to build a system from the ground up.  I won’t get into the details about how these models are built, just which ones you really really need. In another article, we’ll talk about the benefits of modeling.  As you may be well aware, a picture is definitely worth more than 1,000 words. I make my living either creating models or mentoring those who do, or developing strategies and documentation around the models those should create.  So basically – I’m biased.

I had a very pleasant interaction this week with an attendee of one of my speeches/seminars at the Enterprise Architectures conference asking “what else do I need to complete this architecture”.  It’s one of the most common things I am asked.

At the end of the day, what you need is very specific to your situation. A model is just a mode of communication.  Each time we build a system or prepare to maintain one, the business issue, driver or problem is different, so each time we should evaluate if our normal model of operation is enough – do we need new models, or even a better question – is there a better model to be used to get my point across?

I’ve often try to help folks on a project for a client who are likely never going to get out of the old world of flowcharts and cutting & pasting old mainframe code into word documents and adding a bit of pseudo-code and calling it a Use Case.  It doesn’t help when they ask “when do I need an Activity Diagram, or a Use Case Diagram” and I answer “it depends”.

Don’t start saying I’m the same as the rest of the consultants – I actually follow up with some questions about what they are trying to do and what they are trying to say.  In a nutsell, each system architecture needs the minimum to survive:

– A High Level Business Use Case Diagram (includes use cases that map at the domain level, rather than at the specific system activity level)

– A Class Diagram focusing on Entity Classes (your Logical Model)

– A Physical Model depicting the database plans

– Some type of GUI prototype or model

– Some Architecture documentation that describes non-functional requirements, navigation within the system, technical architecture and security architecture (these will include these models)

Bear in mind – these are the minimum that should be included.  In addition, when one gets really confused and delayed in writing the use cases, use case diagrams, collaboration, sequence, state and activity diagrams should be used.  Deployment diagrams are handy when it is complex.

These diagrams are time-consuming to create, and should be used especially when a new pattern or new components are being introduced.  Again – it’s supposed to be common sense, and my sympathies go out to you if you are burdened by an application manager or architecture manager who has a checklist to be completed with each project, irrespective of the tasks at hand.

Sidenote:  Don’t forget that updating an old diagram is the way to go on any maintenance tasks.  Old models are great to use as a base, and if you have them, even if paper-based, dust them off and get going.