Kiwis Can Fly

Visit… you know you want to!

  • Kiwis can fly Moved to

    The blog is now here.
  • Advertisements

5 Lessons from Architecture Camp

Posted by kiwiscanfly on April 16, 2007

Just got back from the nz dot net user group architecture camp in Auckland, here’s some of the best of what I discovered:

Lesson 1 – Don’t stay in a student flat and expect to get much sleep.

I was staying at my mate Anthony’s place, a typical student flat where I slept on a really grotty couch that makes a racket whenever you move and has a bar that digs into the worst possible places no matter which way you lie. But it was fun to work all day and party all night, and catch up with friends in the so called “big smoke”. But on Sunday I was struggling to keep my eyes open most of the time, never again.

Lesson 2 – Kicking the bucket is better than sleeping with the daises.

Metaphors are out, they suck, they bring too many expectations, which bring along assumptions, and we all know what happens when you assume! But seriously, metaphors can only go so far, and users don’t know when to apply the metaphor and when not to and we want the user to know what to expect. Also, it can be a gamble if someone will understand the connection between an icon and the meaning. Anyone who has played Pictionary knows that the meaning of a picture is not always clear. Most visual elements of the GUI are better as idioms. A scroll bar, for example, is not a metaphor for anything in the physical world. It is an entirely new construct, yet it performs an obvious function, its operation is easily mastered, and users easily remember how it works.

Lesson 3 – Types of software patterns

Design Patterns

Structural Patterns

Structural patterns are used to define the composition of objects and control access to subsystems of objects. Using the analysis model in the context of solution’s structure, the architect can begin defining the frameworks in the context of the structural patterns.

In contrast to the architectural patterns which define an entire solution or subsystem, there are usually a number of structural-design patterns in a single framework.

Behavioural Patterns

Behavioural patterns are concerned with algorithms and communication between objects. Behavioural patterns address issues like which behaviours are applicable in which state of an object, and which algorithm is applicable for a particular object for a given context.

Creational Patterns

Creational patterns are concerned with the instantiation (and destruction) of objects. The creational patterns focus on the composition of complex objects and the encapsulation of creational behaviour.

Architectural Patterns

An Architectural Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.

Domain Patterns

Domain Patterns have a very different focus from the Design Patterns and the Architectural Patterns. The focus is totally on how to structure the Domain Model itself, how to encapsulate the domain knowledge in the model, and how to apply the ubiquitous language and not let the infrastructure distract away from the important parts. They are about making the Domain Model clearer, more expressive, and purposeful, as well as letting the knowledge gained of the domain be apparent in the Domain Model.

Lesson 4 – REST Rocks

As you can see in this blog posting, REST can appear complex on the surface. But really, it’s quite simple, it’s all about the URL and the header, that’s it. Here’s the basic idea, check out the powerpoint in the base4 blog for more info:

Lesson 5 – Key Levels of Architects

An “architect” is a role, it’s not a title or an activity, its a “hat”. An architects role depends on the person and the team, but as enterprises evolve, the hierarchies tend to shift toward the following pyramid.  To quote from MSDN:

A Pyramid of Architects

Any enterprise that has a large stake in information technologies (IT) is best served by having experts who understand the importance and the need for integrated solutions, and have the expertise to build such systems.

These experts can have many different titles, but I will describe them as a hierarchy of architects. Their job is to align the enterprise I.T. needs with business goals. They need tools that can help them achieve those goals. I will first describe the architectural hierarchy, and then describe the tools that can be used to allow the various professionals to communicate.

The pyramid in Figure 1 shows the hierarchy of architects in a typical enterprise.

Figure 1. An enterprise has many different levels of architectural experts.

At the top is the strategic architect. This is the person who is responsible for overseeing the overall strategy of the information technologies areas of the enterprise. This is often the Chief Technical Officer, the Chief Information Officer, or someone else in an executive role.

The enterprise architect will usually oversee many applications and projects. He or she is responsible for cross-platform applications and their architectural decisions.

There are two more types of architects that exist in the enterprise. One of them is called a Project or a Solution architect. The project architect is responsible for a specific application and its architecture.

There are also Operational or Deployment Architects. A Deployment Architect is responsible for defining the operational requirements and executing the deployment of an application from an architectural standpoint.

Of course, this type of hierarchy does not exist in every organization, but I believe that, as enterprises move towards reusable services, an organizational structure such as this will evolve.


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: