Architects Plot : English

The Battle for Clouds

PasiM — Thu, 01 Oct 2009 08:32:00 GMT

Cloud computing is still controversial new technology. It’s under debate what is it good for and what benefits does it offer. Some people, like the authors of InfoQ article “Cloud Computing for the Wrong Reasons”, think its a tool in search of it’s use. They do identify some niche’s for cloud computing. I found amusing the idea of using cloud computing for gaming via server based 3D-rendering with cheap terminals. If these folks had ever played any real-time 3D games, they’d know that the latency would destroy the experience.

To give a view on what cloud computing is and how to use it, I’ve written together with few partners a paper “The Battle for Clouds”. The paper gives overview of cloud terminology and presents a reference model for cloud platforms. The reference model is used to compare major cloud platforms and analyze how cloud computing influences practical business system architectures. The paper includes description of two solutions based on Microsoft Azure platform; Sopima Contract Managent and Sproodle.

I’d like to express my thanks to the other authors Aali Alikoski, Antti Makkonen and Nicklas Andersson.

I would enjoy hearing how you see cloud computing.

[Edit 1.10. 14:30: Corrected the link to the whitepaper.]

Architecture of a Photograph

PasiM — Fri, 24 Feb 2006 00:07:00 GMT

Since architecture is a viable approach into analysing and designing many areas like city structure, buildings, businesses and ICT, could one use the approach to analyse the constituent parts of a photographic piece of art? To come up with an architected photograph?

What is then architecture? Traditional definition is the art and science of designing buildings and structures. In ICT and business, it's similarly about structure and principles governing the design of business and ICT. Structure can be different business and ICT services and their relations to each other. So architecture is both art and discipline.

Architecture is also about separation of concerns. Separating the WHY from WHAT, HOW and WITH WHAT. Each level of abstraction has concerns that are best understood by keeping them separate:

The WHY concern is about the context that the design has to exist in.
The WHAT is about the needs that the design should satisfy. In business and ICT they are often expressed as set of required services and their interrelations. The services describe the first conceptual design.
The HOW is about the logical structure the design should have.
The WITH WHAT is about the physical implementation.

WHY do I photograph? What is the context of my photographs? Some do it as a profession, preferably getting both material and intellectual reward out of it. Some may photograph as a way to express emotions, as a form of therapy. Some photograph for themselves, never actually sharing their work outside a close circle. Some are driven by competition and the desire for recognition. I guess the whole field of photography and the related forms of art are also part of the context. Even if I'm not aware of all of them, they do still influence how people interpret my photos. Contextual elements for a photograph could be:

Photographer and his or her values, beliefs, goals and knowledge
The planned audience and their beliefs and values
Art of Photography
Other related arts
Society in general

WHAT should a photograph aim to achieve? Naturally the context of the photograph influences this decision. What is the equivalent of business or ICT service in a photograph? If we think photography as communication and influencing, then the service is the affect we desire to achieve. A list of conceptual 'services' could be:

Conceptual subject that we are trying to communicate about (Me, You, Them, A Product, Opinion, Belief …)
Emotional affectors (similar to effector or actuator) driving an emotion like joy, sadness, disgust, lust, etc.
Intellectual affectors offering facts, information, proof, disproof, etc.

(I know the word affector is not proper English, I’m open to suggestions.)

HOW should we then achieve the desired affects? The photographer needs to select one or more concrete subjects to represent the conceptual subject. The background may be chosen to support the affect. The affect is further modified by other logical elements and the composition between them.
Logical elements of photograph could be:

Subject(s) and its shape, colour and texture
A background or lack of it
Light and its direction, intensity and colour
Contrast between colours, intensity of light, textures and subjects
Viewpoint and the exclusion or inclusion of subjects
Composition of subjects and background

WITH WHAT can we then implement the physical photograph? Here we should consider the technicalities of making a photograph. Everything from the time of capture, lights used, lens, exposure, media and processing to the delivery media of the final photograph. Thus the physical or implementation elements of a photograph could be:

Time of capture (time of day alters the intensity, direction, colour and softness of light)
Lightning equipment and modifiers to supplement and alter the available light
Length of exposure
Lens defines the angle of view and point of focus
Aperture controls the depth of field
Capture devices may alter our image
Capture processing may make further modifications to the image
Capture media is able to represent a certain part of the view
Post processing can be used to achieve the desired logical elements
Intermediate media may impose further restrictions on what may be represented
Delivery processing may be required to render the photograph
Delivery media and environment have the final effect on the photograph

In business and ICT architecture, best results are achieved when all four abstraction levels are mastered. I’d say the same holds true for great photographs. And I have lot to learn on Photography!

Image copyright Pasi Mäkinen, unauthorised reproduction prohibited.

Architects role within the MSF Process Model

PasiM — Thu, 23 Feb 2006 16:06:00 GMT

I’ve been reading through the Microsoft Solution Framework Process Model. The model in its current incarnation does not include a specific role of Architect. There is a Solution Architecture sub-role as part of Program Management Role Cluster.

I think the model is correct in specifying the solution architect responsibilities as:

Owning the logical design
Providing the link between the business and technology sides of the solution
Custodian of the functional specification
Ensuring traceability of features back to requirements

In addition to these responsibilities, I think the Architect could also be a valuable partner for the Product Management role in refining the requirements. Early requirements need to be refined into more specific ones. By designing the solution concept as formal conceptual architecture and linking the requirements to the components of that architecture, potentially conflicting or ambiguous requirements can be spotted more easily.

This approach places a requirement for tooling support. Linking of requirements to specific components of architecture model should be supported. In addition to the benefits for Requirements Modelling, linkage would also allow easy linkage from Test Cases via Requirements and Architecture Model to the Implementation Component that needs to be fixed.

Welcome to the Architects Plot!

PasiM — Thu, 23 Feb 2006 11:51:00 GMT

[Plot:

the arrangement of incidents that (ideally) each follow plausibly from the other (Aristotle's Poetics),
drawn graphical representation of data,
a small piece of planted ground or
a planned conspiracy ;-)

Source: Wikipedia]

I decided to start this blog as a way to share the architecture related ideas and information I come across when discussing with clients, partners and colleagues. I do try to include something of my own whenever that rare opportunity occurs. ;-)

My background in architecture is mainly from my time with the Capgemini Group. Because of that, I am inclined to include business, information, information systems, infrastructure, governance and security as architecture aspect areas. Similarly, I tend to break the architecture into abstraction levels of contextual, conceptual, logical and physical. So you’ve been warned!

When I joined Microsoft as an Architect Evangelist (somewhat amusing title from Finnish perspective), I was positively surprised by some architecture related concepts within Microsoft. Related to business architecture the most exiting finding was the Motion methodology for discovering resilient business capabilities to base the service model on. The idea being that business capabilities change less often than business processes and are more similar between organisations within an industry.

Another well kept secret from outside world was the Connected Systems Model describing not only the traditional service orientation aspect of SOA, but also including the viewpoints of service consumption, workflows, identity and data federation. Not to forget modelling and management to unite the whole.

I’m accustomed to seeing different architecture aspect areas connected at the service level (business services supported by information system services that run on top of infrastructure services). But this line of thought was limited to architecture design time. The Dynamic Systems Initiative aims to extend this traceability into deployment and production time also. Imagine if distributed systems weaved out of several services could be deployed and reconfigured automatically. Metrics relevant to business decisions could be provided by smart systems management tools that understand the structure of systems and how they relate to business processes and goals.

Via this Plot, I hope to be able to share and exchange some insight on the role of architect and use of architecture as a tool for both business and IT. Some of the material will be in Finnish. I will be also writing about my other passion, photography.

I hope you find this Plot interesting, or at least slightly amusing ;-)