The theme of this topic is to provide the audience with enough cross-discipline appreciation for what goes into a software development effort. The theme of the discussion is about your survival and what you should know and do to survive. Again, taking the perspective of having your life at stake. If you will, think of this discussion in line with: “what if you only had one more year to live. What would you do?” You’d probably get really serious and discriminating about how you’d spend your time. Types of efforts: Transaction-based, control-based (rules), planning-based (reporting). Different types of software intentions call for different types of talents. Many systems evolve from transaction-based to planning-based to control-based. Appropriate technologies for different intention types. E.g. the role of database in an application. For some apps a vendor-specific rdms feature set may be appropriate. For other intentions the vendor-specific rdbms is a liability.

Each member has to have a certain passion for the work. I’m coming from a passionate and reflective perspective on the work. I’m always searching for finding the essence of things and exploring path to improvement.

The discussion will be based upon my highly opinionated perspective of software development based upon twenty years. I will review the problems and their respective solutions that will be infused with the dilemmas and brick-wall frustrations. Partition the discussion into coarse-grained segments that meld together into to a point. Sort of like pouring ideas into a wide-mouthed funnel and each idea finds its way to the same point.

•This discussion is based on my 20 years worth of experiences and interpretations of those experiences. •This alpha-level presentation is an attempt to pull many ideas together to support a point of view – that is: if one truly is committed to delivering solutions, then a certain level of ruthless attitude is necessary. Again, my opinion. QUESTIONS:
How many attendees are DBAs? Exposure to UML
Use UML         

I have many ideas and opinions and I’ll try to stay as focused as possible given my nature during presentations such as this to move off point in the hope of reaching another point to support the original point.

First I want to baseline some ideas so you know where I’m coming from. Much of the following discussion will have links to these perspectives. My perspectives have changed over time as I’ve learned more about converging disciplines and forces.

Creative type - heavy left brain thinking - usually architect and designers, high-level modelers. Spatial Analytical type - often midbrain - able to look at problems “in the large” and decompose those problems into problems “in the small”. Engineer type - Heavy right brain. More linear. Able to deal with problems “in the micro”.

Regarding ruthlessness - software is unforgiving. It works or it doesn’t work. The same should hold true of collaborators in the effort to make the product.

I will use three metaphors to express and support the need for ruthlessness in ensuring necessary and sufficient collaboration in achieving success (as if your life depends on it).

Riff a bit here about my point of view of orchestra vs jazz. Explain orthoxy vs improvisation. One must be completely aware and have deep knowledge of forms before one can play around it.

Relate this to the distinct different between the hardware and software order of magnitude of growth since 1950. Suggest that the notion and codification of patterns may create a noticeable upward blip in the graph.

Often, we start from the middle and not from the top. So that causes downstream problems because nobody really knows what is being accomplished. Particularly when the good old organizational shell game occurs.

This does not have to take much time. Even rudimentary information is better than no information at all. The last generation is still spitting out the last bad taste of the 80’s on the “strategy” topic but soon enough the new generation will realize that if they want to do the right thing effectively and efficiently then they’re going to have to think ahead.

If you can’t measure when you have achieved you don’t know when you’ll get there.

There are several problem definition tools out there but this one is fun.

Talk about patterns again.

These are simple test to determine your own confidence level or of colleagues and candidate colleagues.

Discuss experience that yesterday’s guidelines are not necessarily relevant to today’s technologies and techniques.

Data is too broad a term. For this discussion I’m constraining this to data elements. Individual instances of facts that one requires. Integrating third party applications is too costly and is not the right attitude. Shoe-horning apps has never worked. Avoid folks who promote these ideas. Even trying to integrate in-house applications can be problematic. You’re better off developing adapters to interface between applications than necessarily “pointing” to the same data element. The acquisition of a data element should be a service.

Each phase is a type of iteration. Each of the workflows are repeated for each phase. Each successive phase results in the implemented solution.

Design is a broad topic.

Often, we tend to delve directly into the details of something rather than keep things at a reasonably high level to see the “landscape” of a situation.

Like all methodologies, the RUP is always changing. It get very hard to keep up.

Prayer has no place in the working of software. Of course, you can pray for a great idea, or understanding or to remember a pattern or structure that is relevant to the problem.

This is where the rubber meets the road. Acquiring and keeping talent and teams is paramount to success at any level. The best specified requirements will not guarantee success if the team is not maintained.

The Architect is a kind of Conductor that orchestrates and guides the components into forms that meet the business needs.