Most often getting business architecture requirements right is a challenge and it means there are two types of people who need to converge at a common point to where they could make sense it each other. The business people are concerned with the business side of things and look at the picture from an angle which could be quite different from the IT folks. For example the IT team is worried about building requirements that are more better versions of working software or rather refinements in releases but the business is concerned about what business value will this piece add to the overall product strategy or solution point of view. Many a times it so happens that there is no clear articulation of business value and organizations spend time and effort in producing waste or MUDA ( Toyota / Six Sigma ) prefers to call it. This can happen because in the name of taking up an initiative a wrong requirement was envisaged as having to be completed.  Many a times the requirements although is an art and science by itself and needs to be done with the right focus as all the downstream actions based on this can create mis alignment in the vision and mission of an enterprise. So is there is definitive prescription to doing this , how is this similar to user stories or epics that agile teams talk about . User stories are not enough to detail all possible requirements more so when they depict the end to end system goals where aligning business and IT is paramount. This being the case there needs to be a structure to capture all the actors and details that goes into getting a business scenario right.

Recently been to an IT company where the issue was product owners hand over requirements over email or chat sessions or simply over a phone call. It was said that requirements not getting correctly scoped was the single most productivity loss and created enormous amount of wasteful downstream activities. What has been your experience here ?

Joint introductory webinar with KnowledgeHut on 23 Jan 2015.

Like all presentations mostly end up starting with a glitch , this one also started with one . Please watch it from 3:51 onwards.

Overview:

Business is always in a constant state of flux- more so these days, with disruption happening all around. How do you move from your AS IS state to TO BE architecture in your enterprise transformational journey? What mix and match of people, processes and technology will you blend together, and in what proportion, to drive enterprise value to deliver transformational results? TOGAF® framwork has a suite of tools that can help architects to chalk out the architectural roadmap for enterprise success. This talk will also focus on how agility is an underlying thread in this framework, and how value is delivered incrementally, making the process robust and bankable.

This webinar is an introductory session to walk one through how TOGAF® as an enterprise architecture framework has proven best practices that can be used to drive results.

Key Takeaways:

Exposes the audience to the features of TOGAF® framework which help plug business technology gaps.
– How TOGAF® Standard has agility at its core to drive transformational results.
– Why it is a good skill and knowledge for a seasoned IT professional to have in their kitty.

References / Acknowledgements

1. www.opengroup.com/togaf
2. http://forums.juniper.net/t5/Industry-Solutions-and-Trends/Meatballs-and-Spaghetti-how-to-untangle-the-cloud/ba-p/121808
3. Roger Sessions — http:/msdn.microsoft.com/en-us/library/aa479371.aspx/

Avoid BDUF ( Big Upfront Design) and keeping adding value in increments and iterations. Fail fast and learn in the iterations.

Think Services and not reusable code when abstracting business functionality . Code re usability is usually a failed model and leads to stick to each other architectures and is best avoided.

Agility and Architecture uses a common tip to speed by agility amongst teams and is known as “Centralize Interoperability and Decentralize Implementation. There is a detailed blog on the same on the site here  for more details. This tip is inherently used by many architectural frameworks such as Togaf and even project management frameworks.

With a backdrop of the traditional waterfall mechanisms of project management, build and release was always pushed aside as the last but one activity before cutting the CD / testing certification of the software. The last mile as it was referred to this although was the last step in the journey towards a software delivery it would remind one of the famous lines the “Journey has just begun”.

Although this was the last step supposedly to be taking 20% or less of the actual effort it generally would be the other way around , taking a significant effort and often not scoped in estimates and it was quite OK to do so till recently. Start the blame game and developers blaming QA and vice versa and everyone including the other teams would take potshots at each other and say their part worked fine but the had issues in the final integration. All of this started to be stage managed with late nights and weekends going into getting all pieces talking to each other is all very familiar with traditional methods in place.

What next ?

There are some best practices such as the following that are being followed where everything is continuous meaning

Continuous Delivery
Continuous Integration
Continuous Deployment

What all of this means in short is every time you change any part of the product the whole SWAT team runs behind the scenes to check if all is OK with the system. Now if someone were to check in something that breaks the system then it needs to be fixed then and there. Have seen that code needs to be fixed corrected by the erring developer/team by the same night. There are protocols like call the guy involved to get it right and ensure only code that is working is checked in . All of this boils down to the Agile concept of everything that is checked in is tested and fit for deployment into production post a formal QA team blessing the product. But otherwise the usual suspects are nailed down early and the QA goes on to find the more grueling aspects of the product committed features which have escaped the unit testing/TDD iterations.

If something out here still finds its way to the bug tracker then the developer needs to take care of UNIT TESTING / TDD best practices on ensuring his/her code works well under all circumstances and integrates with all the surround infrastructure and allied pieces of software. Software ownership and craftsmanship are truly enforced here as this goes in a loop till the process achieves some predictability on the process.

DevOps in a five line code snippet for starters.