Niraj Bhatt – Architect's Blog

Ruminations on .NET, Architecture & Design

Category Archives: Uncategorized

TOGAF – Quick Reference Guide

TOGAF is The Open Group Architecture Framework – a framework for Enterprise Architecture. In this post I am going to provide a summary of this framework to create a quick easy reference for fellow architects. Open group reports TOGAF is employed by 80% of Global 50 companies and 60% of Fortune 500 companies, if that motivates you to adopt / learn this framework.

So what’s enterprise architecture? Who can be an enterprise architect (EA)? Should every IT architect aspire to be one? Architecture word in enterprise architecture still conveys ‘organization of a system’ just that you are now alleviating from system level organization (typically tiers / layers) to an enterprise level organization of business capabilities & supporting IT ecosystem. If you are a system architect (SA) you can certainly alleviate to an enterprise architect, though you need to weigh it appropriately. EAs are different beasts. They certainly have more visibility, are close to business,  up in the corporate ladder (due to alignment with overall enterprise), but at the same time they aren’t too close to technology. So if you rejoice technology, enjoy being close to code, trying out cool stuff, being hands-on with innovations, etc., EA may not be the right thing for you. EA’s role is lot more involved with business, people and processes. Now I am not saying EAs don’t mess around with technology, or SAs don’t deal with processes, but ratios are mostly skewed.

Now let’s understand what TOGAF has to offer. TOGAF essentially provides guidance for going about enterprise architecture. To start it recommends a methodology for doing enterprise architecture called ADM (Architecture Development Method). It then goes on describe typical deliverables produced throughout the ADM (Content Framework), how to logically organize them (Enterprise Continuum) and store them (Architecture Repository). For enterprise starting fresh there is guidance on creating architecture capability and how to adopt / adapt ADM for a given organization. TOGAF aims at being comprehensive, and often gets cited as being bloated (or impractical as critics call it). This is true to large extent. I haven’t come across an organization that follows TOGAF verbatim, at the same time there is hardly to find an organization EA practice that hasn’t been influenced by TOGAF. Hence it helps to look at TOGAF as a reference guide than a prescription.

Let me answer one last frequently asked question – Is TOGAF dated / dead? After all, version 9.1 was released in December 2011. Isn’t that quite long in today’s rapidly changing word? Is TOGAF still relevant? Or what’s the use of TOGAF in a digital world? As mentioned earlier, TOGAF is not bound to technology advancements such as Cloud, AI or Digital. TOGAF framework holds and will work with any underlying technology. For instance, when SOA (Service Oriented Architecture) emerged there was no modification done to TOGAF ADM, rather TOGAF provided additional perspectives as to how SOA would map to ADM phases (may be Open Group could have released a SOA whitepaper, rather than integrating that guidance in TOGAF publication). The same applies to other technology initiatives. As an EA you should have a handle on market innovations, and how your business could leverage them, but how you go about aligning those stays the same.

With this background let me provide you with a quick overview of TOGAF components. At heart of TOGAF is the ADM method consisting of Phases A-H, along with a preliminary phase and centralized requirements management.

adm

  • Preliminary Phase is used to identify drivers and requirements for architecture work and capturing outcome in Request for Architecture work document. Depending on organization EA maturity this phase will also be used for defining architecture principles, establishing enterprise architecture team / tools, tailoring architecture process, and determining integration with other management frameworks (ITIL, COBIT, etc.).
  • Vision phase (phase-A) focus it to elaborate on how new proposed capability will meet business needs and address stakeholder concerns. There are various techniques like Business Scenarios which TOGAF recommends for assisting in this process. Along with capability one needs to identify business readiness (organizational), risks involved (program level) and mitigation activities. Outcome of this phase is a statement of architecture work and high level view of baseline and target architectures (including business, information systems & technology).
  • Next three Phases B, C, D are to develop these high level baseline and target architectures for each – business, information systems (apps + data) and technology (infrastructure), identify gaps between them and define the roadmap components (building blocks) which will bridge that gap. These architectures and gaps  are then captured in architecture definition document, along with measurable criteria (must do to comply) captured in architecture requirements specification. At the end of each phase a stakeholder review is conducted to validate outcomes against the statement of architecture work.
  • Phase E is Opportunities and Solutions. Goal here is to consolidate gaps across B, C, D phases, identify possible solutions, determine dependencies across them and ensure interoperability. Accordingly create work packages, group these packages into portfolios and projects, and identify transition architectures wherever incremental approach is needed. The outcome of this phase is a draft architecture roadmap and migration plan.
  • Next Phase F is migration planning. While Phase E is largely driven by EAs, phase F will require them to collaborate with portfolio and project managers. Here the draft migration plan is further worked upon assigning business value (priority) to each work package, cost estimates, risk validations, and finalizing migration plan. At the end of this phase both architecture definition and architecture requirements document are completed.
  • In phase G (implementation governance) the project implementation kicks in and EAs need to ensure that implementations are in accordance with target architecture. This done by drawing out architecture contracts and getting those signed from developing and sponsoring organizations. EAs will conduct reviews throughout this phase and will close it out once the solutions are fully deployed.
  • What’s guaranteed after phase G is ‘change’. Organizational drivers do change either top-down or bottom-up leading to changes in enterprise architecture. Managing this change is what phase H is all about. Here EAs perform analysis of each change request, and determine if the change warrants an architecture cycle of its own. This often requires an architecture board (cross-organization architecture body) approval. Typical outcome of this phase would be a new request for architecture work.
  • Central to these phases is requirements management. Requirements management is a dynamic process where requirements are interchanged across phases and also at times between ADM cycles.

In addition to ADM, TOGAF offers guidelines and techniques which will help you adopt / adapt ADM. For instance, there might be cases where you might skip phases or change order of phases. Consider an enterprise committed to adopt packaged solution, where you might do business architecture after information systems and technology architecture. Other is where you develop target architecture before baseline architecture to ensure there is more effective transition (not getting boxed into the existing capability). In both these cases you are adapting ADM to your specific enterprise needs.

Next let’s discuss architecture deliverables for each of the phase. We spoke about architecture definition and architecture requirement documents. Wouldn’t it be nice if there was a meta-model which would dictate the structure of these documents ensuring there is consistency across ADM cycles? This is where architecture content framework (ACF) comes in. Metamodel for individual artifacts can be thought of as viewpoint from which view (a perspective for related set of stakeholder concerns) is created. TOGAF categories all viewpoints into catalogs, matrices or diagrams. Furthermore these viewpoints are used to describe architecture building blocks (ABB), which are then used to build systems (ABBs are mapped to solution building blocks (SBBs) in phase E).

contentfwk

So now we have enterprise architecture development methodology and a way to define its deliverables to ensure consistency. What else? How about classifying and storing these artifacts? If you look at a large enterprise there could be hundreds of ADM cycles operating at any given point in time. Each of these cycles would generate tons of deliverables. Storing all the deliverables in a single bucket would lead to chaos and minimal reuse. This is where enterprise continuum (EC) along with architecture and solution continuum comes in. Continuum is used to establish an evolving classification model starting from Foundation to Systems to Industry to Organization for all the architecture artifacts. These artifacts, along with content metamodel, governance log, standards, etc. is stored in architecture repository. There are two reference architecture models included in TOGAF documentation – first one is TRM a foundation level architecture model and second one is III-RM which is a systems level architecture model.

Finally framework gets into the details of establishing architecture capability within an organization. It talks about the need of Architecture Board, its role and responsibilities, including architecture governance (controls & Objectives) and compliance (audit). For the latter two TOGAF includes a governance framework and compliance review process. Guidance also touches upon maturity models (based on CMM techniques) and necessary role skill mapping.

That was TOGAF summary for you. I strongly encourage to read open group publication. Many find it a dry and lengthy read. But it’s the best way to learn TOGAF and a must read if you want to clear the certification. Though it’s highly unlikely that getting certified in TOGAF will overnight establish you as an enterprise architect, but it’s a first good step in that direction.

All the best for your exam, if you are planning for one. Hope you found this post useful!

Client Profitability vs. Practice / Company Profitability

This post is for dummies covering few business terms which I am dabbling with these days. Thoughts below are primarily related to software services, but I think they would be of help to any service industry.

Having ran a startup earlier, I have always cared for margins which is necessary for the healthy growth of the business. Before getting into a customer engagement getting your margins or simply put profits right is very important, for both fixed bid and T&M (Time and Materials) projects. Apart from resource costs, you also need to take into consideration other costs like T&E (Travel and Expenses) and call them out separately.

Keeping above in mind, the profits you derive out of a given customer project is called Customer or Client Profitability (CP) – usually measured in terms of percentage. So, is good CP all what a company should care for? Answer is, of course not. While you might have a high CP it’s still possible that the overall company or practice is making loss. Let’s see how.

The common reason for discrepancy here is overlooking the fixed costs. For instance, you are going to incur salary costs irrespective of whether your resources are allocated (billable) to a project or not (e.g. project you signed up for got over in 5 months) and you will have to still pay rent, infrastructure bills, etc. All of these expenses fall under the larger category called SG&A (Selling, General and Administrative Expenses) which includes advertisement, sales, taxes, training, corporate functions, etc. In short, the Practice Profitability (PP) is not a sum of various CPs; rather it’s Sum of CPs minus SG&A.

It should be clear by now that the only way you can grow your business is increment CP without proportionally increasing SG&A; i.e. do more with less. Most of the budget planning exercises in corporate companies is around this agenda. One way to achieve this is move away from RFR (Resource following Revenue) to non-linear revenue models, shifting the focus from services to products.

Hope this was useful in putting these terms into the right perspective.

Single Sign On via Cookie Sharing for Sub Domains using ASP.NET

ASP.NET supports Forms Based Authentication (FBA). FBA mandates that user logging to the site must have an .ASPXAUTH cookie. If the cookie stored on your computer is persistent it would bypass the login screen next time to access the site. This happens because every time you send a request out to a site, all the cookies stored for their site on your computer travel along with the corresponding HTTP request. Now this holds true not only for site per se, but also holds for any sub domains of that site. For e.g. if you have a persistent cookie stored for abc.com, the authentication cookie would not only be send to abc.com, but also xyz.abc.com and pqr.abc.com.

So the question comes how do set the domain name for an authentication cookie in ASP.NET? Pretty simple, use GetAuthCookie method of FormsAuthentication class.

HttpCookie httpCookie = FormsAuthentication.GetAuthCookie( “someuser”, true ); //Persistent Cookie
httpCookie.Domain = “somedomain.org”; // Set the domain
HttpContext.Current.Response.Cookies.Add( httpCookie ); // add the auth cookie to response
Response.Redirect( FormsAuthentication.GetRedirectUrl( “someuser”, true ) );

Note the second parameter passed to GetAuthCookie – ‘true’. This would create a persistent cookie. This cookie would be send to the sites in the same domain and so would bypass the login screen. Also it’s the machinekey which is used to generate (encrypt / decrypt) the authentication cookie. Hence, you need to ensure that machineKey is same for all the applications which are part of your SSO solution as shown below:

<system.web>
<machineKey validationKey=”64Bytes” decryptionKey=”24Bytes” decryption=”3DES” validation=”SHA1″/>
</system.web>

You can find more details about how to generate these keys with differences between decryptionKey (used for authentication ticket) and validationKey (used for viewstate) here.

Finally the GetAuthCookie code won’t work if the machine name where you are running the application and the domain name used don’t match. To do the same you might have to edit your ‘C:\Windows\System32\drivers\etc\hosts’ file and provide an alias. And that’s it. You are all set with your SSO solution.