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.

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. 

Eturnti Consulting is now an Open Group Member and have the commercial license to consult and train on TOGAF 9.1. Being part of the Open Group provides you privilege access to whitepapers and content produced from thought leaders from all across the industry. One key benefit to being part of the group is it happens to be vendor neutral and and focused towards any technology platform although the open standards contribute to making companies leverage on the common strength of the best practices gathered from across diverse verticals and industry segments. You need a tribe to grow your sphere of influence and being seen having a strong presence in your area of interest. Being part of a larger community helps you banking on the common strength of the community and has the advantage of taking your offerings to a larger audience. Apart from having used some Open Group standards for SOA, ARM 4.0 (application response time measurement) , Security and has a bankable list of assets which can be a ready reference when confronted with some industry issue that you end up dealing with for the first time. Learning from the past experience of certain projects and collective strength of the community is a good way forward for reaffirming your gut on certain things especially when you as an organization does not have prior experience in that area and want assistance.

Looking forward to leveraging the benefits of the Open Group for meaning dialogues and partnerships with organizations.

All the frameworks invariably touch upon the need for an architect to go from high level strategy to execution. How seamlessly you move from one to an other determines your maturity as an architect.

It is always better to keep a separate rack for storing your office or household items. Separation of concerns as it is referred to in architecture ensures that each layer in the architecture owns up what it is meant to and works towards making it happen. This is needed as you go along from strategy to execution although the lines blur as you make this layered transition.Ability to talk business to the end users and technology to your internal teams is a vital asset.This needs constant zoom in and zoom out of the details involved.

As you grow up as an architect you need the ability to see the forest from the trees. You need to understand the details involved in lets say moving a data center in the cloud at a very high level where you see only the building blocks ( arranging the logistics involved , assessing the impact of the solution, deciding which cloud hosting provider ) involved and also down below where you can get to see the actual pieces ( actual cloud provider , data migration / backup / restore , day to day running of the cloud setup , load balancers, network providers,security solutions co-hosted) of the solution. As you move from vision to execution the details start emerging which perhaps may have been a one point on your check list. This gets full blown as you move towards the bottom of the pyramid and all your skills arsenal will be put to good use.

Want to take something from idea to hit the ground It all starts with a context in which you want to solve the problem. All start ups may go through this this process but who cares about a framework when you need to hit the ground with your product. Nevertheless the thought process is pretty useful and serves you well when you move towards rolling out other products and solutions in the length / breadth of your career.

1. Contextual Vision of where you want to go ( mission/vision)

This the domain or the context in which your problem exists or manifests and you want to solve it. Mostly it is the 20,000 foot level.

Let’s say you are designing Facebook The high level mission statement is connecting people.

2. Conceptual level  (flesh out the context into concepts ) : This level of detail is more detailed than the earlier one where now you are moving one level below. The context is set and now the concepts get hashed out as to what aspects of the context you need to flesh out the details. Having defined the need for people to connect lets say over social media is out high level goal. What aspects of them same do you want to take it to the next level of details which will include how they will interact , what privileges do they share among each other and what kind of business process or data interchange happens between them and so on. Once these details are etched out , it becomes clear as to what building blocks are required to make this happen. List all the business processes , the actors involved in the process and all the other surrounding pieces that are needed to complete the interactions between the entities involved.

3. Logical ( Group them under a bucket/functionality etc)

Now the the problem having been defined at the conceptual level we need to see how to arrange them at a logical level. This generally would mean how to organize the pieces such that they are devoid of the underlying intricacies, technology stack that they run on. This also assumes that it excludes the implementation details as long as the blocks can be grouped into logical blocks for which a particular functionality be assigned or grouped. All the blocks that constitute the business , data , application and technology areas would be grouped together. Under each bucket we could have relevant sub buckets say under business all blocks dealing with people interaction, relationship manager,profile updater and so on will fall under this.

4. Physical ( Leave it to Implementation)

This is generally the last layer below the logical layer where you can decide to have a logically grouped solution being implemented using any of the technology choices on the table or leave it to implementation. The layer post this will be actually code or executables. Here.if the logical solution has grouped the architecture into entities based on functionality , at the physical layer they could be implemented on a java stack or C# stack or ROR stack. The ability to abstract the high level details from the implementation is a key asset for an architect. Ideally one should architect something which can sit on any stack and should be technology agnostic.One such thought process is as long as the database interfaces are logically well defined. It would not matter which underlying database adapter (MySQL,Oracle,MS SQL etc) fulfils the needs for achieving the same. This helps the architect to help think of the solution independently without being constrained by one single solution.

Finally remember strategy formulation is just one step on your path to doing something. Anyone can steal your ideas , strategy and not your execution. Understanding this and walking the talk using architecture best practices help you gain value from all the combined understanding of frameworks.