Saturday, December 29, 2007

Leadership Qualities

This excellent list of leadership qualities is taken from the 'Aspiring Architects' webcast series by Mohammad Akif.

  • Ask thought-provoking questions that result in actionable technological patterns or solutions
  • Actively mentor others
  • Provide thought leadership by enabling others to see things from a different of better perspective
  • Influence decision makers
  • Champion structure, process, best practices and standards
  • Promote the capture and reuse of intellectual property
  • Effectively build individual partnerships and organizational networks

The valuable qualities below were also mentioned during the series. 

  • Practice diplomacy, negotiating and compromising
  • Manage and clarify expectations

Friday, December 28, 2007

The Winchester Mystery House

I've recently been investigating architecture, more specifically SOA and came across an Architecture Journal book entitled SOA in the Real World.  I'm unsure of the author but Chapter 1 is certainly an entertaining and informative read.  I was fascinated by the reference to the Winchester Mystery House and it's history formed the basis of a New Years message for my team.

The Winchester Mystery House is an intriguing tourist attraction in the USA near San Jose, CA. The Winchester Mystery House was the home to the heiress of the Winchester fortune (amassed from the sales of Winchester rifles). According to the legend, the heiress went to see a fortune teller and learned she was cursed to be haunted by the spirits of everyone ever killed by a Winchester rifle. The only way to avoid the curse was to build a mansion – as long as she kept building the spirits would leave her alone. She promptly hired 147 builders (and 0 architects), all of whom began working on the mansion simultaneously. The builders worked on the mansion until the heiress passed away, 38 years later. The result of their efforts is a classic example of implementation without architecture:

  • The mansion contains 160 rooms, 40 bedrooms, 6 kitchens, 2 basements and 950 doors
  • Of the 950 doors, 65 of them open to blank walls; 13 staircases were built and abandoned; and 24 skylights were installed into various floors.
  • No architectural blueprint for the mansion was ever created.

Confusing architecture with implementation generates chaotic and unpredictable results – much like the Winchester Mystery House.

Let's try not make the same mistake with software construction in 2008 ;)

Saturday, December 22, 2007

Favourite Archipedia Entries

Another Useless Acronym (AUA)
Another Useless Acronym (AUA) or what can happen when partially formed new architectural ideas emerge.

When something has the capability to perform an indispensable task that no one thought was even possible.

Bottom Up Design
Bottom up design, as with its counterpart Top down design, are strategies of information processing.
In the Bottom up design approach, individual parts of a system are designed in detail and the design parts are then linked together to form larger components, which are then in turn linked until a complete system is formed. Often the bottom up approach assumes that all facts are known up front as the detailed parts are designed.

In the Top down design approach to modeling an overview of the system is made, without going into detail and each part of the system is then refined by designing it in more detail. Each new part may then can be refined again until the entire specification is detailed enough. Often the top down approach is used when not all facts or constraints are known about a design.

Formally a choreography can be defined as a declaration of the activities within collaboration and the sequencing rules and dependencies between these activities.

Often these days, when people talk about the architecture of business services there are 2 related concepts which often come up - choreography and orchestration.

The difference between the two is easy to remember depending on your design perspective. Seen from a publicly observable view of a service, choreography is the description of how to interact with the service to consume its functionality. Seen from the same publicly observable viewpoint, orchestration is how service functionality is achieved ("within" a service) by aggregating some service logic and very possibly other Web services.

Time, resource and effort that ought not to be wasted. "Let's not waste any cycles on something that doesn't matter."

A portion of one's capacity to perform work. "Do you have any cycles to burn on the ...".

Drinking from the Fire Hose
Having an overwhelming amount of information thrown at you, commonly at the start of a new job or project.

Ivory Tower Architecture
An architecture developed in isolation from the developers, or teams of developers, responsible for following it.

Keep It Simple Stupid is a design philosophy that states simplicity lasts and simplicty is needed to properly convey any ideas. Simplicity is the absence of unnecessary elements. Simplicity isn't a design style, but a perspective on design and an approach which often creates the most usable and beautiful results.

Low Hanging Fruit
Management expression for the most available and easy to accomplish objectives.

Operational Requirements
A category of requirements that describe the operational expectations for a system, such as availability, security, performance, scalability, manageability, interoperability, and reliability.

These requirements are distinct from the functional requirements that detail the business functions that the system performs (e.g., calculating the total bill for a shopping basket).

Also called "non-functional requirements"; also called "non-behavioral requirements". Closely related to the concepts "aspects" and "qualities".

Portfolio Management
Portfolio management is a function of IT Governance (which makes it fair game for enterprise architecture). The portfolios in question typically include both the application portfolio and the service portfolio. The focuses of portfolio management typically include:

  • Redundancy analysis -- avoiding having (and paying for and maintaining) multiple artifacts that perform essentially the same function;
  • Gap analysis -- identifying opportunities to improve processes through better automation;
    Manageability -- standardization of management interfaces, including vendor selection based on adherence to standard metaphors for management;
  • Cost rationalization -- analysis of the true ROI of automation and elimination of non-cost-effective systems;
  • Server consolidation -- reduction of the number of systems being supported, often by standardizing to a small set of server operating systems.

Project Stakeholder
Project stakeholders are any of the interested parties in a given development project. Typical examples of stakeholders include:

  • Business process owner -- the person responsible for the profit-and-loss of the business process being supported;
  • End user -- the people who will actually use the system under development;
  • Operations -- the people with the pagers whose sleep is at risk;
  • Executive sponsor -- the person who can light a fire under non-responsive stakeholders;

As well as architect, project management, developers, and testers, naturally.

The term "quality" is used in two distinct ways in systems architecture. The first usage is to define a class of common properties that must be addressd by any system. These "qualities" include:

  • Security
  • Manageability
  • Availability
  • Reliability
  • Scalability

These system qualities may be cross-cutting concerns for the system, and hence may be best addressed using some form of aspect-oriented programming.

The second usage is closer to the typical English-language usage: how well the system meets the requirements that were defined for it. For a more complete look at this meaning, please see quality management.

Rat Holing
A slang term for a discussion that spirals away from the topic of the meeting.

Return on Investment (ROI)
A calculation of the economic value being derived from a system as compared to its costs.
When embarking on a new initiative, it is common to predict an ROI for the system under consideration. This calculation needs to look at both development and ongoing operational costs for the system. The calculation is used as a justification for moving ahead with the project.
Once a system is in operation, ROI calculations ignore the "sunk costs" of development, and only compares the value being realized with the ongoing costs (which are more fully understood once the system is in operation than it was when the project was being envisioned). This calculation may, however, consider depreciation of assets that support the system, such as computers and storage devices.

A taxonomy is a system of classification and with context, such as enterprise or folks or something else, a taxonomy is a description of the context.

Time-to-value is the elapsed time between the commitment to a project and the perceived realization of value from the investment. Project planners who stress short time-to-value seek to maintain excitement and emotional engagement around the project. Long lags between project inception and perceived first value can cause business process owners to disengage from and deprioritize the project.

Waterfall processes proceed through a unidirectional sequence of discreet steps.

The term is principally applied to a software development methodology that promotes a sequence along theses lines:

  • Conceptualization -- business process owners identify a business need and develop a conceptual model for a solution;
  • Requirements definition -- solutions architects work with business process owners to produce a detailed functional specification;
  • Project definition -- the functional specification is used to generate a set of work items for development;
  • Development -- Developers and test engineers produce and validate a set of deliverables in accordance with the project plan;
  • Acceptance testing -- the resulting system is tested for compliance with the functional requirements;
  • Deployment -- the system is put into production.

Critics of waterfall methodologies question how effectively the requirements for a software system can be understood "up front". They promote more agile approaches to software development.

Don Ferguson Quotes

"There is no point in building the Emerald City without building the Yellow Brick Road; and you have to build the road first."

"Vision without execution is hallucination."