Sunday, May 26, 2013

TOGAF Overview

In this series of blogs, I will try to summarize TOGAF, The Open Group Architecture Framework. I have done my TOGAF9.1 certification in year 2012. I have been part of two teams which were in transitioning phase from a baseline architecture to the next generation architecture.

TOGAF is an Enterprise Architecture Framework which has evolved from best practices in EA development. The two teams I worked with were not following TOGAF, but several practices they followed overlaps with TOGAF. Based on that experience and the knowledge I have gathered via TOGAF certification I will be writing this blog. Your comments will help me refine it further. I will mainly refer TOGAF documentation while writing this blog.

You can adopt TOGAF as your enterprise architecture framework or you may wish to adopt parts of the TOGAF framework and use them with your existing EA framework. TOGAF works well in both these scenarios.

Before diving into TOGAF, let’s see what an Enterprise Architecture work involves. An Enterprise Architecture encompasses the entire enterprise which starts from the business. When you have Enterprise in your perspective, the entire thought on architecture changes. You do not begin from thinking about 2-3-n tiers, High Availability, Messaging, etc… but your perspective now is what are the business processes and how IT can help evolve or support these business processes. You begin with understanding the Business Architecture, what Architecture Principles will your applications be based on, what will be your Architecture Roadmap to support these Business processes, who your stakeholders will be and how will they be managed, what is the current architecture (if any) and are there any Gaps to support the business processes, how to store reusable Architecture Building Blocks, how to Migrate from existing architecture to the target state architecture, what all applications will be required and how will they be governed, how will a change in architecture be implemented… and the list goes on.

Implementing Enterprise Architecture is not a one person job and neither is it a single project within Organization. It’s a practice which must be setup within the organization and recognized and funded from the CXO level. Enterprise Architecture Practice is not a standalone ivory tower effort. It works in parallel with the PMO and the Operations.

So, will you then not be thinking of 2-3-n tiers, High Availability, Messaging, etc. That depends on what sort of Architect you are. If you are an Enterprise architect, you will think of these when you define architecture principles. If you are a Data Architect, you will define Data Aspects. As an application / solution architect you will identify tiers, messaging in accordance with Architecture Principles laid out and if you are a Technical architect, you will define high availability platforms. Roles and responsibilities of architects will vary in different organization.

I hope this gives a glimpse of what is involved in an Enterprise Level Architecture. TOGAF provides an architecture framework which defines a process following which you will be able to develop an Enterprise Architecture.

TOGAF is developed by The Open Group and consists of seven parts:

1.       Introduction – TOGAF Introduction and common Terminologies and definitions

2.       ADM – Architecture Development Method – An iterative methodology of how to develop an Enterprise Architecture. It has 9 Phases and each phase has Objectives, Steps, Inputs and Outputs. Eg. In Preliminary Phase, one of the objective is “Identify and scope the elements of the enterprise organizations affected by the Architecture Capability” and one of the input is “Board strategies, business plans, business strategy, IT Strategy, business principles, business goals, and business drivers” and an output is “Request for Architecture Work”.

3.       ADM Guidelines and Techniques – This describes several guidelines and techniques which can be applied when performing ADM. Eg. How to do a Gap Analysis?

4.       Architecture Content Framework – When developing Architecture via ADM, several outputs will be produced (Eg. Project Plans, Architecture Definition Document…). The Content framework provides a way to structure and present these outputs. All outputs of ADM is categorized as a Deliverable, Artifact or a reusable Building Block and the content framework provides definition of each of these. The content framework also provides a meta-model for to structure outputs from all phases. This provides consistency among different architectures.

5.       Enterprise Continuum and Tools – Within an organization, there will be a continuum of architectures from foundational to specific architectures. This part of TOGAF classifies the entire spectrum and also provides guidance on how to partition the architecture and how to maintain Architecture Repository.

6.       TOGAF Reference Models – TOGAF provides two reference architecture models. Technical Reference Model (TRM) and Integrated Information Infrastructure Reference Model (III-RM). TRM provides a foundation which includes services and functions required to build more specific architectures. It essentially is a taxonomy of components and structure which is generic to all architectures. III-RM is also a taxonomy and is applicable to organization which have silos and would need information to flow out and aggregated.

7.       Architecture Capability Framework – Provides guidance on how to setup Architecture capability in the organization in a Phased manner.

This blog provides an overview of what TOGAF has to offer. This introduces you to several terms without going into detail. I hope the blog still offers enough information to inspire you to give a look to TOGAF.
In the next blog, we will look into the different Architectures supported by TOGAF i.e. the Business, Data, Information and Technical Architectures.

Wednesday, April 24, 2013

Practical Scrum - Story Point Estimation

This blog is about how to come up with a release plan using story point estimation technique. I am writing this blog while I am working on sprint 4 of our project. We are following a two week sprint cycle and our project will be completed in Sprint 8. When I say sprint 8, it’s the commitment from my entire team and we have not estimated any of our tasks in hours.

I am the tech lead, developer and the scrum master on my team. I also write integration tests. Scrum master can be a dedicated role as well as shared one.

This blog assumes that you understand scrum, so will not explain what a story point is or what velocity is. In a line, Story Point is an abstract measure of size of user story and velocity = total story points burned in a Sprint.

This is how we began to estimate our Release date. We added all our stories to product backlog. We use Jira as scrum tool. The stories were then prioritized and based on priority, we selected 30 user stories for our first release. These story names were then written on sticky notes. Then we called for a release planning meeting.

This meeting happened four times with a duration of 1 to 1.5hrs each. Participants were the entire team which is three developers (including me), 1 tester and product owner. We used Fibonacci sequence as story point estimation technique. We gathered in a room, sat on a big oval table and created 9 virtual columns. Column headers were 1, 2, 3, 5, 8, 13, 20, 40, and 100.

Product owner picked a medium complexity story (complexity was decided by me as medium). Then he started explaining what that user story means, what all it involves and when will it be considered complete. All team members asked questions to get more clarification. Ultimately everyone’s query was answered. Team discussed that as part of this user story we will need some UI changes, a new method in business logic, some normal stored procs and roughly 2-3 automated integration tests. They trusted me that based on entire stack it is a medium complexity and placed it in column numbered 5.

Then we picked next story, product owner explained and team asked questions and thought among themselves that what will be required technically at a high level. They concluded that this story is less in complexity than previous one but was not very straightforward too. As it was low in complexity so it was kept at column numbered 3 to the left of column numbered 5.

Next story went to column numbered 13 as it was more complex than the one we placed in column 5. Next went to column numbered 1 as it was the easiest one. Then the next story was thought of between 13 and 20, but as we did not have any other column, I asked team to put it in 20.

The stories which went to 40 or 100 was discarded by me. I asked product owner to break these further before next meeting so that each short story is 20 or less. There were few 13 and 20 numbered stories which logically could be split to shorter independent ones. This was done instantaneously and the new stories then moved to 5 or 8 numbered columns.

Before you get bored, let me say that this went on and after 4 meetings, all release 1 stories were in one of following columns 1, 2, 3, 5, 8, 13, 20. During these discussions, some moved to backlog and others were picked from backlog by product owner as he got more understanding from team inputs.

Team again trusted me and kept iteration length as 2 weeks. We started coding sprint 1. We did a sprint planning meeting. How we did it will be covered in another blog. At end of sprint 1, we checked how many stories we completed. We completed two from column numbered 5, one from column numbered 13. Total sum of story points completed in sprint 1 = 2*5 +13= 23.

In sprint 2, we completed 20 and in sprint 3, we did 22 story points.

From this we deducted that we are doing an average of Math.Floor((20+22+23)/3) = 21 story points in one sprint. We have total 160 story points estimated in our Release 1. So with 21 as average, we should be done in sprint 8. Each sprint being 2 weeks plus schedule and feature buffer, we now have a release date with us.

This is just one of several methods of estimating a scrum project. Others are via historical results, or via forecasting by deducing hours as documented in Mike Cohn book Agile Estimating and Planning chapter 16.

In this blog, intentionally to keep it simple, I did not explain sprint planning meeting and also did not talk about certain things like project schedule buffers, backlog grooming etc..

I will extend on few of these points in part 2 of this blog.