We understand people can’t always make it to a classroom, so we have leveraged virtual technologies, to extend the classroom to you – at your workplace or home to provide you with the same feel.Attend TOGAF Trainings from anywhere over webex. The training schedule for webex is listed here.
Key Features of the Online Training
Similar to a classroom based training except that the material will be presented over webex / gotomeeting webinars. The class is made quite interactive using bamboo presenter as an illustrator which gives the classboard feel.
All students will be provided with URL information, to link to the webex/gotomeeting class that they have signed up for, the required lab facilities, and a toll free number for completely integrated audio.
Interactive lecture, labs, and discussion are all enabled by making the participants the presenters when needed to enable a seamless classroom experience.
There will be tea/coffee/bio breaks just as in a classroom training session.
The material of the course (hard copy) shall be mailed to the folks attending the course and a full ebook of the TOGAF 9.1 body of knowledge shall be mailed to the course attendees.
Pre Requisites for attending the Online Training
People attending the training need to have a decent internet connection to be able to
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.
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/
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.
Most often get asked this question by experienced, very experienced and people with little experience folks on what happens to my career if you are certified in TOGAF 9.x ( version immaterial) . For that matter lets look at what is the value add from get that additional degree or title against your name that you get out of any certification or a degree.Most often you still need real world experience with it to make sense of any learning be it certifications or degrees.Some thoughts on what motivates people to look at acquiring these ….
1. Your resume looks impressive. 2. Potential job offers may flow for you in that direction 3. May get me a pay hike or increase or a lateral or job move. 4. Gain knowledge and become a trusted authority or person and look like a seasoned IT professional who can now talk the same mumbo/jumbo and gain professional respect. 5.Currently do not have the title of an architect / Want to move along the career as an architect and may be the certification can help 6.Have been entrenched deep down with a specific technology and domain and look forward to see the whole picture.
While the above are some common concerns. Lets look at the value proposition of TOGAF though not covering all aspects in its entirety.
TOGAF Elevator Pitch
TOGAF value explained in an elevator pitch can be stated as it is a methodology to manage your architecture while moving from AS IS to TO BE state. Mind you , your AS IS can be anything from that reflects your current IT landscape. You can be in anywhere on your journey towards accomplishing your mission and how do you go towards getting there all the while caring about agility and not keeping an eye on cost and accountability on your IT spend.
TOGAF helps one understand the nuances of IT transformations(digital is more cool now) and what is involved.
What does getting certified in TOGAF mean ? Industry values experience when it comes to solve complex problems out there at that the customer has. You as an architect has to step in and do the magic of having the right mix of people, process and technology to deliver what is needed to ease the end user pain point. Companies in the least value a person who has such certifications with the idea that such an exposure will help a person at least think in that direction instead of being raw with no experience except for some deep dive experience in say one particular area. It helps you have a T profile for an architect. Helps one scale from a solution architect to an enterprise architect. It helps you to look at the problem from a broader perspective of how it impacts the stakeholders in the company , outside , skills , technology and process to have them all work towards your mission /vision as a company.
A fool with a tool is still a fool – TOGAF No Exception
It is akin to a person clearing PMP need not necessarily be a good manager. As any framework it does expose people to a good set of principles while dealing with people , process and technology and the inherent value in applying them in practice. At the outset it is too general but with applying the organization context to it , it becomes meaningful. Which augurs with the sentiment that a fool with the tool is still a fool. Mere knowing the framework without knowing how it can be tailored for an organization is what makes it abstract for people not having the relevant experience in business and IT transformations. The other reason also being the maturity of the organization who tend to relate the pieces of the framework by the book in a prescriptive fashion without checking on what suits their organization context. Same with agile prescriptions where have heard people say scrum says so we do it. Not really checking on how much of it is really relevant in their particular context. Scrum purists may dismiss this as SCRUM BUT , reality is different and not necessarily by the book. Togaf does not inherently project itself as having a strong agile backdrop to it. But the principles are very much there and it is for the practitioners to present that flavor to the end audience with agility at its core.
Customer Sentiment – What do you know about my problem and context ?
As can be known from experience there can be no single silver bullet to IT transformations , each customer is a case study in itself. The larger the portfolio , the more difficult it is to straight jacket it into a group. Experience comes by walking alongside the customer apart from the knowledge at hand.They call this as Management by Walking Around ( MBWA) instead of an MBA alone. TOGAF exposes architects to a methodology which mature organizations have used as best practice and earned value. Many of the companies in the fortune list have used it extensively and have tailored them to suit their stack and solve their individual issues.