Tuesday, November 29, 2011

Communicating Architecture : Key Terms of 42010

This is in continuation to my earlier post Understanding ISO/IEC/IEEE 42010:2011 : Standard for Architecture description. If you have landed directly to this post, I recommend to read the earlier post first.

Reposting the conceptual model of the Standard for easy reading.


In this I will discuss the key terms of the Standard.

Architecting :  contributes to the development, operation and maintenance of a system from its initial conception through its retirement from use and disposal. It is performed throughout the system life cycle.

AD Element : Architecture Description Element. The  most  primitive  construct in AD. Every stakeholder, concern, architecture viewpoint, architecture view, model kind, architecture model, architecture decision and rationale is considered an AD element.

Stakeholders : anyone who has interest in the system. e.g.

  • users
  • operators
  • owners
  • suppliers
  • developers
  • maintainers

Concerns : interest in a system relevant to one or more of its stakeholders. e,g, technological, business, operational, performance, resource utilization, etc.

Viewpoint : establishes the conventions for the construction, interpretation and use of architecture views for specific concern(s). A concern can be framed by more than one viewpoint. Viewpoint conventions can include
languages, notations, model kinds, design rules, and/or modelling methods, analysis techniques and other
operations on views.

View : expresses the architecture of a system from the perspective of specific system concern(s) in accordance to its Viewpoint.

Model Kinds : conventions for a type of modelling. e.g. class diagrams, data flow diagrams, etc.

Architecture Model : An architecture model uses modelling conventions appropriate to the concerns to be addressed. These conventions are specified by the model kind governing that model. Within an architecture description,  an architecture model can be a part of more than one architecture view.

Rationale : Architecture rationale records explanation, justification or reasoning about architecture decisions that have been made. The rationale for a decision  can  include the basis for a decision, alternatives and trade-offs considered, potential consequences of the decision and citations to sources of additional information.

Decision : something which affect the architecture in context of a concern.

Correspondence Rules : Correspondences are governed by Correspondence Rules.

Correspondences : defines a relation between AD elements. Correspondences and correspondence rules are used to express and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation.

Architecture Framework :  conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholder. Uses of architecture frameworks include, but are not limited to: creating architecture descriptions; developing architecture modelling tools and architecting methods; and establishing processes to facilitate communication, commitments and interoperation across multiple projects and/or organization. e.g.

  • Zachman’s information systems architecture framework
  • UK Ministry of Defence Architecture Framework
  • The Open Group’s Architecture Framework (TOGAF)
  • Kruchten’s “4+1” view model
  • Reference Model for Open Distributed Processing (RM-ODP)

Architecture Description Language (ADL) :  An ADL provides one or more model kinds as  a means to frame some concerns for its audience of stakeholders. An ADL can be narrowly focused, defining a single model kind, or widely focused to provide several model kinds, optionally organized into viewpoints. Often an ADL is supported by automated tools to aid the creation, use and analysis of its models. e.g.

  • Rapide
  • Wright
  • SysML
  • ArchiMate

Understanding ISO/IEC/IEEE 42010:2011 : Standard for Architecture description

Approved on 10 Nov 2011, ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description, is the latest edition of the original IEEE Std 1471:2000, Recommended Practice for Architectural Description of Software-intensive Systems.
This standard replaces IEEE 1471:2000. It is identical to the ISO standard approved in July. The new standard, designated ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description, is available from IEEE and ISO.
In March 2006, IEEE 1471 was adopted as an ISO standard. It was published in July 2007 as ISO/IEC 42010:2007. Its text was identical to IEEE 1471:2000.ISO/IEC/IEEE 42010:2011 replaces both ISO/IEC 42010:2007 and IEEE Std 1471:2000.
Here is the composite and simplified view of Architecture and its ecosystem.
The storyboard for reading this diagram goes like this:
  1. System which belongs to an environment addresses concerns of its stakeholders.
  2. Every system has architecture
  3. Architecture is described using Architecture Description(AD)
  4. Stakeholders use AD to understand architecture
  5. AD is created using Architecture Frameworks (AF) and Architecture Description Languages (ADL)
  6. AD includes following:
    • Stakeholders and their concerns
    • Architecture Viewpoints & Views
    • Architecture Model kinds & Models
    • Architecture Rationale & Decisions
    • Correspondence Rules and Correspondences
  7. Architecture Viewpoints include Model Kinds
  8. Architecture Views include Architecture Models
  9. Views are governed by Viewpoints
  10. Models are governed by Model Kinds
  11. Architecture Rationale justifies Decisions
  12. Correspondence Rules specify Correspondences
So, what does this Standard contains ?
This Standard defines & specifies conformance requirements on contents of following:
  • Architecture Descriptions of systems
  • Architecture Frameworks
  • Architecture Description Languages
  • Architecture Viewpoints
The Standard defines architecture this way:
fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
This post is first in the series where I will try to explain this standard. In next post I will try to go into details of various AD elements.

Part 2 : Communicating Architecture : Key Terms of 42010

Part 3 : Architecture Description confirming to ISO Standard

Thursday, November 24, 2011

Pillars of Agile Development


Businesses & CIOs across the world see lot of value in going Agile for Software Development. Development teams also have been quick enough in adopting the Agile methodologies. But in majority of cases, teams have failed to capitalize on the value of Agile development and in fact reduced their efficiencies by going Agile. There is also a trend where teams have started reverting back to the old way of software development.

The primary reason for this failure is that teams have failed to understand what it takes to get value out of Agile. Just by doing SCRUM or hiring a Scrum master doesn’t make you agile. In fact it creates chaos. Going Agile is a multi-dimensional approach and is based on three foundation pillars. If the team is not matured enough in even one of these, they will fail to get value out of going Agile. Higher the maturity in these pillars, more effective the agile approach will be.

The foundation pillars of Agile Development are:

1. Test Driven Development. It is about coding against tests instead of requirements. Requirements are translated into test cases and developers code to satisfy those test cases. This considerably reduces the testing cycle but increases focus on writing right test cases.

2. Agile Project Management. This is about correctly prioritizing the requirements and right sizing the iterations. I am sure everyone must have heard stories about Google having a sprint cycle of 2 days and Facebook having it of less than a day. Start with a sprint size with which the team is comfortable, even if it is 30 days. As you mature in other 2 pillars, you can start reducing your sprint duration.

3. Continuous Integration & Deployment. This is the last leg of an iteration and requires lot of support from tools. It involves building & integrating the code frequently, running automated tests and moving it to production. Some of the tools like Microsoft TFS, Cruise Control and others can help in this.

So, if you are planning to go agile for your development make sure you address it from all sides.

Tuesday, November 22, 2011

Compare Clouds : Microsoft vs VMware

Microsoft has recently released an interesting white paper comparing its private cloud offering with that of VMware. As expected the focus is mainly on cost & licensing.


Apart from comparing its solution with VMware, the whitepaper provides some excellent details into its own offering which can be a nice read for understanding Private Cloud architecture & ecosystem.


Monday, November 21, 2011

This is called Customer Experience

Most of the companies today irrespective of which industry they are in, are focusing a lot on customer experience. But some companies take it real seriously and even do not hesitate to break the long running traditions.

Recently I was answering a feedback survey of an airline and was amazed to see by the simplicity of the options of the survey. While most of the surveys will have numbers (1 to 5)  or (excellent to poor) to rate satisfaction, this survey actually tried capturing the emotions of the customer by giving options as real as actual emotions.


Though they forgot to provide the same experience with ‘N.A.’ which an average customer may not be able to decipher.

Thursday, November 10, 2011

Cloud and Enterprise IT : Partners or Competitors


Businesses across the world have been long frustrated with the slow response times of their IT departments in terms of provisioning new infrastructure. Now that Cloud Computing is available, IT teams have been slow in adopting it too.

There has been a recent trend which I am seeing ( I am sure you too ) where businesses have directly started dealing with public cloud providers and get the infra quickly. Though business teams have to take ownership of associated risks in this case but for them agility is more important to survive.

So, how are things going to turn up in future. Are we going to see downsizing of Enterprise IT teams ?

Tuesday, November 8, 2011

London Olympics 2012 CIO : Cloud computing not yet ready to host Olympics


London Olympics 2012 CIO Gerry Pennell has an interesting take on Cloud Computing & its ability to host mission control systems.

Even CIOs of most of the financial institutions think that Cloud Computing needs more time to build the trust required for mission critical systems.


UK : How Government plans to spend less on IT


UK Cabinet Office’s recent ICT Strategy & Strategic Implementation Plan (SIP) highlights how it plans save money or spend less money on IT with the right spending.

Here are few of the things government plans to do:

  • Creation of Public Services Network (PSN)
  • Move to the Cloud
  • Datacenter Consolidation
  • Preference to Open Source
  • Adopting Agile way of delivering Projects instead of Big ones
  • Consolidate Application Portfolio

This seems to be a decent list which even most of the enterprises plan to execute to control their IT spending.


Sunday, November 6, 2011

CIOs : Same Vision but Different Goals

IBM’s recent CIO study brings out a very important fact about the diversity in mandate which CIOs worldwide face.

The mandate spectrum spans from as legacy as digitization/computerization to IT being expected of radically innovating.

The report categorizes it into four following zones:

Leverage : Streamline Operations and increase organizational effectiveness

Expand : Refines business processes and enhance collaboration

Transform : Change the industry value chain through improved relationships

Pioneer : Radically innovate products, markets, business models


Every organization’s priority lies in one of these zones and so it becomes very important for CIOs and their teams to operate according to their organization and not just focus on ‘Pioneer’.

But still with all these different expectations with regards to goal, the Vision remains same and that is of creating value for business.

Another fact which report highlights is the industry distribution across these zones. The figure below shows distribution of industries in Pioneer zone.


It clearly shows how Financial industry is pioneering in terms of using IT to their advantage in terms of innovating.

Saturday, November 5, 2011

Disaster Recovery, BCP and Cloud

Few days back I blogged about the spirit with which BCP or DR should be planned. Continuing on that here are two recent whitepapers published by Amazon and Microsoft on utilizing cloud as DR environment.


This paper talks about how Amazon’s AWS can be used as a DR environment and how various AWS services can play role in that including S3 and EC2.

It also includes backup and restore.




Microsoft’s paper takes more holistic approach which includes how Windows Phone can participate in an event of DR.