SCRUM : Why I like it so much

Scrum. It’s that point in the game where the guys all get together to discuss the finer points of ball management. They set a plan, huddle together and execute.

That’s not a million miles away from SCRUM, that agile software development framework that IT professionals use to execute and keep track of IT development projects.  I like it, because its simple and the status of the project is clear at any point in the iterative cycles.  There are little rules in SCRUM, but its a clear and to the point framework.  The whole point of scrum is to ensure that regular iterative cycles called sprints are undertook and at any point in those cycles the state of the development is made clear, usually in meetings that have the team stand, which so far, I like because they last about 15 minutes max.

The general flow of a development project being conducted with the SCRUM framework applied would look like the following:

Set a SCRUM Master (basically the project manager / project leader). Work with your subject experts and business analysts to identify a worklist and set of features the product being developed is to include (normally based on the functional requirements). This work list is commonly known in SCRUM as the product backlog.  Based on the finalized backlog, work with the development team to order the product backlog in priority order.  In my experience, this happens following some work with general architecture design of the product, so lots of UML diagrams and talk of design principles and patterns by the lead Enterprise / Solution Architect(s).

Once the order of work has been set, the product backlog is split up into sets of ‘sprint backlogs’ which illustrate the list of tasks to be performed during each ‘Sprint’.  Sprints are the iterative development cycles and tend to range in time between 2 to 6 weeks or so (at least in my experience with SCRUM).  The aim of the sprint is to have an area of the product in a ‘ship ready’ state by the time the sprint ends, so that should mean that the unit tests have been carried out and the QA guys and gals have signed off on the work.

During the sprint, daily team catch up meetings (huddled in headlocks of course 😉 take place to ascertain the state of play each day.  Being open and transparent in these meetings is the key to ensuring the sprint will finish on time.  In the SCRUM meetings I have taken part in, there is generally a rule within the team that there is no bad news, just be clear and no friction will arise.  No one care’s if you’ve not finished something, just be honest so the team can handle it during the current sprint.  In my experience, a playback of development to the customer occurs at the end of each sprint.

The workload and project timeline is normally set out against the burn down chart. This is a popular diagram with project managers / Scrum Masters because its a visual indication of whether the project is ‘burning down’ enough to land the project on time for delivery.  By understanding in advance whether the sprints are delivering, you can understand whether additional resource or cost injection is needed in order to finish the work in the timescale agreed with the stake holders.  There’s nothing worse for a project manager or programme manager than being grilled by the board because a project is over run and over budget.

I’ve certainly had my fair share of involvement in projects that have overrun and have gone well over budget (who hasn’t 😉 and these are non SCRUM projects.  I’m a fan of SCRUM because of its honesty about each sprint’s state of development.  You know exactly where you’re at every day and because everyone does tend to stand in my experience (you don’t have to), people are quick to update and get to the crux of matters because they wan’t to sit down. This leads to quick identity of issues and resolution of those issues.

I’m a fan of SCRUM and I’d love to hear about projects implemented using this framework that have been delivered both on time and within budget… Comments please!

Oh and last but not least, Happy New Year!


Enterprise Architecture : An Introduction

As a budding Enterprise Architect, I’ve always been interested in the bigger picture when it comes to how an organization plans, executes and maintains its IT infrastructure.  Before we jump into what Enterprise Architecture is as a concept, we need to understand why IT is such an important function of any operating organization and reiterate why IT remains the back bone of a business.

Information Technology in the eyes of an organization is one of its Strategic Assets. Assets are a businesses economic resource (something owned that has material value) that for the most part adds value.  Organizations deploy this asset in supporting the business via new technology / development and the day to day task of running the IT ‘engine’.  An example of where IT supports the business would be the availability and advanced analyzing of sales or marketing data that can make or break a business decision and which could ultimatley effect the businesses position in the market.  What is important to remember here is that the goal of any business or organization or division or department is never fixed.  Goals of all sizes are moving targets and so the IT infrastructure that supports that business/organization must continue to improve and grow to support these goals.

A quick tour through the IT generations

IT didn’t just appear as a business function overnight, it developed through generations of supporting business processes. Here is a quick look at the story so far:

First Generation IT (G1) – Developed in the 70’s to support ‘batch based’ business processes. Batch based processing was a collection of automated series of programs (jobs) that had no human intervention. Batch based computing mainly occurred on main frame computing environments.

Second Generation IT (G2) – Emerging through the late 80’s to early 90’s was ‘Closed Multitask computing’ where programs could individually run threads of processing at the same time. This period saw the advent of Windows.

Third Generation IT (G3) – Emerging in the mid 90’s this period saw the ‘connected’, online accessibility era. The face of the business became the web site and new business models were born.

Fourth Generation IT (G4) – 2000 – The ubiquitous (everywhere), always connected service based architecture that IT departments strive for today.

Fifth Generation IT (G5) – 2015+ (who knows?)

As businesses move between these generations of change, massive IT infrastructure investments are made.  A good example to follow how business processes have changed throughout the generations is to look at the Banking sector.  In the 70’s you could only perform your banking duties between certain hours on certain days of the week and you had to go visit a physical branch.  Transactions where processed in batches on a day to day basis and statement printing was also carried out in batches so you would only know how much money you had on a monthly basis.  Today, banks offer global access to your money, statements and global online trading has changed the face of investments.  All of your banking information is available in one of two places, 1) via your personalised internet banking web portal and 2) via global ATM network.

Because of these continual improvements to banking IT infrastructure over the years, banks are thriving as a business and essentially run the cities of the world with their cash (except when the government / tax payer has to bail them out because of a global recession of course, but let’s not focus on that 😉

So What is Enterprise Architecture

Enterprise Architecture is one of those subjects that can easily invoke tongue twisting. The official ANSI/IEEE definition of EA is :

“the fundamental organization of a system, embodied in its component objects, their relationships to each other, the environment in which the objects reside and the principles governing the systems design and evolution”.

Makes sense right?  The Metaphor would be the design of a city (think Sim City).  The architectural blue print details the roads, utilities, open spaces (parks) and their locations / interactions.  Using this example utilities are the technologies and frameworks employed,  roads provide the communication and networks and the open spaces / parks are the applications and systems and how they interact with each other.

Whats the goal of enterprise architecture then?

It’s important not just to pass the definition of Enterprise Architecture without mentioning the ultimate goal of Enterprise Architecture.  The goal is to create a unified IT environment (so common hardware, platforms and technologies using open/common standards), create an alignment of the technology with the business, to make use of or ‘re-use’ existing IT assets and finally, promote the sharing of project management / software design approaches across the enterprise.  The end result at least in theory is that the Enterprise Architecture (blueprint, roadmap etc) will make IT investment cheaper, make IT more strategic, and ensure IT is more responsive to
business change.

Enterprise Architecture has 4 basic domains (according to most EA frameworks):

Business Architecture – Documentation that outlines the company’s most important / business critical processes (the most critical domain but also the most difficult to implement)

Information Architecture – Identifies where important blocks of information such as a customers data are kept and how that data is accessed.

Application System Architecture – A map of the relationships of software applications to one another.

Technology Infrastructure Architecture – The blueprint for the hardware, storage systems, and networks.

In terms of skill sets for the aspiring Enterprise Architect :

(1) Business Process Modelling, Design, Re-Engineering (BPMN, BPEL, BPM Servers)
(2) Database Administrator / Designer (SQL, LinQ, Database Design, RDBMS)
(3) Software Developer / Architect and Enterprise Integration techniques (Middleware, API, Software Dev Platforms / Frameworks)
(4) Network and Hardware specialist (Servers, Common Server Roles, Network Stack incl Protocols, Topology planning, Operating Systems, Hardware)

Breaking the Enterprise Architecture down

An enterprise is a whole corporation, a division of a corporation, a government agency, a single department, or a network of geographically distant organizations linked together by a common business goal / objective.
Enterprise architecture relates to understanding the collection of child business entities/objects that comprise one of the above enterprise definitions and how those elements interrelate.

Enterprise architecture =

Business Processes       + Applications       + Technologies        + Data

People                                          Systems                        Communications          Information
Processes                                    Software                       Services
Business Drivers

An architecture is blue printed
A road map plans the delivery of that architecture

A quick note on Governance

The primary purpose of enterprise architecture governance is to ensure that an organization’s IT investments are closely aligned with business goals and processes, so that limited IT resources are allocated to areas of highest impact on organizational performance. Enterprise Architecture governance has its own framework but we won’t get into that now.

Enterprise Architecture Frameworks

Layered frameworks and models for enterprise architecture have proved useful because layering has the advantage of defining contained, non-overlapping partitions of the environment. There is a number of models/modeling techniques, the top 5 most common follow:

1. Zachman Enterprise Architecture Framework (ZIFA or just Zachman)
2. The Open Group Architecture Framework (TOGAF)
3. Extended Enterprise Architecture Framework (E2AF)
4. Enterprise Architecture Planning (EAP)
5. Federal Enterprise Architecture Framework (FEAF)

All of these models seek in one form or another to make use of the concept of a generic service/object-oriented architecture where sets of like functions are grouped into reusable services that can be described as ‘service objects’. More complex capabilities are then built from a combination of these basic service objects just as the elements are made of atoms. For now we’ll leave the discussion of Enterprise Architecture here and come back and discuss a couple of these Enterprise Architecture frameworks in separate articles.

Hopefully this has wet the taste buds for the bigger Enterprise Architecture picture.