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.
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 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.
Exposes the audience to the features of TOGAF which help plug business technology gaps.
– How TOGAF 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
3. Roger Sessions — http:/msdn.microsoft.com/en-us/library/aa479371.aspx/
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.