Get to hear this question from Senior IT folks , Head of Engineering Units , Product Heads , Vice Presidents , Directors when I talk to them during consulting and training engagements . and is quite a common rant from people in charge of gearing their teams efforts of producing a product or a solution. Help teams with getting answers to these questions ( list is not exhaustive enough but indicative) during my TOGAF workshops coupled with real world experience of having seen how companies ( big and small) come to terms with these issues .
When you are developing software eventually ending up in a product or service , there are a few things you wish everyone in the team was or is made aware of.
Questions that the senior most in the team have or the stakeholders have with respect to their teams.
Does my team know what product or solution they efforts are going into ?
Do they know the customer context in which their application is going to be used ?
Do they have any idea on how the customer is going to be deploying the software ?
Do they have any idea on how the software will be customized at site ?
Do they have any idea of how the project will be measured in terms of business outcomes of the project instead of technical prowess alone ?
Do the teams have the knowledge on what is perceived as waste with regard to the requirements that are thrown at them ?
Do they have the knowledge of how to produce just enough architecture or design ?
Do they understand that abstraction is a key asset for an IT professional as they progress along their career path ?
Do they understand what it means to have a separation of concerns in the architecture across the layers.
Do they understand that business architecture is taking a lot of precedence these days and technology is being leveraged to serve the needs ?
Do they know how to slice and dice the architecture or design to produce a Minimum Viable Product or Potentially Shippable Increment ?
Post slicing and dicing the architecture do they know how to put the pieces back and ensure economies of scale in terms of best effort of people , process and technology.
Do they know that the smartest person is not in the room with regard to their requirements if they are continously being changed .
Do they know that external factors and standard can influence the way they go about their work. How can they be proactive here ?
What is best in terms of delivering software these days that which can avoid the blame game and make everyone accountable ?
Do they have a common repository where all the artifacts can be stored in the organization and this reflects the current state and not just created to impress the internal or external auditors ?
Do they know how an idea can be taken all the way from strategy to execution and what are the layers during this process ?
Are they stuck too much on the solution instead of exploring all possible ways of addressing a solution which can result in better customer satisfaction ?
Do they understand that architectures have a short shelf live and should produce ones with that in mind instead of aiming for built to last solutions ?
Built to last should be an architecture goal instead of being a design goal , designs can change .Does the team know this for a fact ?
Do they understand the logical separation across various architectures and how to go about creating deliverables across sprints or scrum cycles whichever may be your organization’s way of doing things ?
Do they constant understand how to innovate in iterations instead of thinking innovation big bang ?
Do they understand the customer needs enough with a bit of design thinking spiced up along in the way they look at solving things.
Do they understand how to fail fast and fail forward ?
Finally do they understand the BIG PICTURE ? DO YOU HAVE SOMEONE in the team who is helping the team understand the BIG Picture ?
Do they understand the complexities of how software which started at a module level and end up being complex as it progress and loses its extensible nature ?
Do they understand the realities / needs of enterprise grade applications or software and are they design and architecture efforts aligned in that direction ?
The above list is not complete but details the issues that senior folks grapple with who are in charge on producing / delivering software. Would love to hear your thoughts on this.
Get to hear this question from Senior IT folks , Head of Engineering Units , Product Heads , Vice Presidents , Directors when I talk to them during consulting and training engagements . and is quite a common rant from people in charge of gearing their teams efforts of producing a product or a solution. Help teams with getting answers to these questions ( list is not exhaustive enough but indicative) during my TOGAF workshops coupled with real world experience of having seen how companies ( big and small) come to terms with these issues .
When you are developing software eventually ending up in a product or service , there are a few things you wish everyone in the team was or is made aware of.
Questions that the senior most in the team have or the stakeholders have with respect to their teams.
Does my team know what product or solution they efforts are going into ?
Do they know the customer context in which their application is going to be used ?
Do they have any idea on how the customer is going to be deploying the software ?
Do they have any idea on how the software will be customized at site ?
Do they have any idea of how the project will be measured in terms of business outcomes of the project instead of technical prowess alone ?
Do the teams have the knowledge on what is perceived as waste with regard to the requirements that are thrown at them ?
Do they have the knowledge of how to produce just enough architecture or design ?
Do they understand that abstraction is a key asset for an IT professional as they progress along their career path ?
Do they understand what it means to have a separation of concerns in the architecture across the layers.
Do they understand that business architecture is taking a lot of precedence these days and technology is being leveraged to serve the needs ?
Do they know how to slice and dice the architecture or design to produce a Minimum Viable Product or Potentially Shippable Increment ?
Post slicing and dicing the architecture do they know how to put the pieces back and ensure economies of scale in terms of best effort of people , process and technology.
Do they know that the smartest person is not in the room with regard to their requirements if they are continously being changed .
Do they know that external factors and standard can influence the way they go about their work. How can they be proactive here ?
What is best in terms of delivering software these days that which can avoid the blame game and make everyone accountable ?
Do they have a common repository where all the artifacts can be stored in the organization and this reflects the current state and not just created to impress the internal or external auditors ?
Do they know how an idea can be taken all the way from strategy to execution and what are the layers during this process ?
Are they stuck too much on the solution instead of exploring all possible ways of addressing a solution which can result in better customer satisfaction ?
Do they understand that architectures have a short shelf live and should produce ones with that in mind instead of aiming for built to last solutions ?
Built to last should be an architecture goal instead of being a design goal , designs can change .Does the team know this for a fact ?
Do they understand the logical separation across various architectures and how to go about creating deliverables across sprints or scrum cycles whichever may be your organization’s way of doing things ?
Do they constant understand how to innovate in iterations instead of thinking innovation big bang ?
Do they understand the customer needs enough with a bit of design thinking spiced up along in the way they look at solving things.
Do they understand how to fail fast and fail forward ?
Finally do they understand the BIG PICTURE ? DO YOU HAVE SOMEONE in the team who is helping the team understand the BIG Picture ?
Do they understand the complexities of how software which started at a module level and end up being complex as it progress and loses its extensible nature ?
Do they understand the realities / needs of enterprise grade applications or software and are they design and architecture efforts aligned in that direction ?
The above list is not complete but details the issues that senior folks grapple with who are in charge on producing / delivering software. Would love to hear your thoughts on this.
Happy to share that Eturnti Enterprise Consulting is now an Open Group TOGAF® 9 Standard Version 9.1 accredited training partner.
Look forward to spreading the TOGAF® Standard Version 9.1 framework body of knowledge across people doing business transformations , IT / digital migrations , overhauling their IT infrastructure/landscape and in short wanting to go from point A to point B in their individual organizational journeys….
TOGAF® is a registered trademark of The Open Group in the United States and other countries.
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/
All enterprise architecture frameworks talk about this. TOGAF also has prescriptions for moving from strategy to execution. Here is a short snippet explaining the process and involves addressing various concerns generally such as domain , data , application and technology without going into all the details. Togaf calls going through this famously as BDAT. ( Business , Data , Application and Technology). More details here.
