Obtaining Enterprise Architecture Metrics – Part 1

For most EA organizations there is a huge struggle to justify their existence. There is quite a bit of criticism on the practice from folks asking, Does Enterprise Architecture Matter? 

The common quote I hear from our EA customers about opposition is simply "Why do we need you" or "So what we are disorganized, it has worked in the past". Debating those points are challenging with out the information to quantify an EA function.

After hearing those statements and questions then there is a mad rush to get the "ROI of EA". The are articles out there they give prescriptive guidance to obtain metrics such as this article. The problem with articles like this is that they make two mistakes. They are unable to clearly Quantify and Qualify the metrics.  See below:

image

So maybe then you are thinking, well let’s align this with the next big EA program such as "future state architecture" processes or strategic programs like what Pankaj Arora talks about with his post on EA ROI. But this approach is flawed because the ownership and accountability of the actual implementation of those ideas are by other teams. You will not get the credit for that great new Online Banking System but rather the e-commerce team.

For the most part EA organizations do not have this quantifiable information. Since they do not, EA’s equip themselves with what I call EA Analyst Battle Cards such as the one below:

image

This was a compile from IASA organization in 2007 from the leading EA analyst communities. 

This is a mistake to carry around EA Analyst Battle Cards because they do not tell your EA customers (e.g., your CIO or CFO):

  • Your EA Value
  • Current State of Your Enterprise
  • The Future Value of EA

What this does show your customers is the potential, that’s it. Gartner, MIT and such provide great data points what’s possible but the circumstances in which these studies derived could be drastically different than what your enterprise looks like.

So what are some of the things you need to keep in mind wen trying to obtain the "right" metrics:

  1. Obtain the Information
    • Know what you can get – Try to avoid a "fools errand run" by knowing what types of metrics you can reliably obtain. If your current processes require guess work in metrics, skip it for now.
    • Get the Tools – To obtain metrics you need tools to collect and store the information. Once the basics are covered, consider automation into the EA process and into specific tooling. The tool sets must allow transparency of the EA process. This allows for self-service metrics from stakeholders.
  2. Process
    • Get a Process – The process must be able to Quantify and Qualify the metrics.
    • Repeatability – All metrics gathering processes need to be repeatable. If not then revise the process. This will ensure the reliability and the accuracy of gathering your metrics.
  3. Communicate
    • Understand your audience – Not everyone is looking for the same metrics, to demonstrate your value you should be able to communicate what they are concerned about.

          image

    • Traceable – Ensuring that the metrics that you are gathering "matter". Meaning that  the metrics you obtain should align with the organizations strategic imperatives. Additionally, demonstrating the validity of the metrics are aligned is crucial.
    • Relatable Information – To successfully communicate value avoid abstract metrics (e.g., Improved interoperability of systems by 40%). Provide information in terms they understand and can "touch and feel". To do this relate these metrics back to strategic programs or projects to demonstrate the tangible value.

 

In summary, the key to success with obtaining the right EA metrics is to have a clearly defined process to obtain the metrics, the tools to get the information and understand what are the right metrics you should obtain.

Remember, numbers are not everything. In many cases value is not always equated to numbers. Perception is very powerful. For example: "Jim was key to the success of this project, he saved the project team from making the wrong decisions in the architecture design process". This is very powerful, and it is difficult to put numbers around it.

In part 2 I will discuss some ways to obtain the right metrics.

 

Tags: Enterprise Architecture

Advertisements

What is the Role of EA in a Dominated SaaS World?

image

A colleague of mine Gianpaolo asked me about what is the role of EA in a heavily SaaS oriented enterprise. The hypothetical case would be of and IT shop being extremely (80%) of the enterprise IT “operations” being run by 3rd parties (SaaS, vendors, hosters, apex like exchanges…) does the need of EA increase or decrease?

I thought that this was an interesting question and made to think about it for a moment. So the specific questions are:

  • If it increases EA effort, are the current “framework” any good in this new model?
  • If it decreases it EA effort, (and assuming we believe in a world where IT will “shrink its perimeter”) how much do we need to invest in EA?

This is a "loaded" topic so I will only be addressing the question directly and not what I think EA’s should do about this in their practices. That may come later :) 

So this is a difficult prediction, it really depends what the specific circumstances were with each particular organization. However, we can generalize and create a assumptions based on what we see today.

  • Assumption 1 – SaaS architectures will be isolated to the application (the more likely of the two) or business capability (ideally) level 
  • Assumption 2 – There is no one vendor fits all
  • Assumption 3 – SaaS providers will use open standards such as web services, however the technology implementation, XML payloads and underlining technologies will be different
  • Assumption 4 – Regulatory scrutiny for items such as information protection, auditing, and reporting will still exist
  • Assumption 5 – There will still be a mixture of implementations of SaaS applications such as Composite Applications (Rich or Smart Clients) and web based solutions.
  • Assumption 6 – Integration will not go away as existing applications in the enterprise and specific business capabilities exposed by SaaS vendors will need to interact with each other.

Based on these assumptions it is safe to say that the role of EA will still be intact. However the specific architecture decisions that will need to be made will vary a bit.

image

Basically what we have done is pushed all the applications to the cloud. Now, instead of provisioning a new HP server and installing Windows Server you use the "cloud" for your application platform. What this does do is it reduces the amount of work needed to manage, operate and support of a server environment. However, this still doesn’t change the larger issue with software applications we have today with Commercial Off The Shelf (COTS) applications. These COTS applications need to be wired together because out of the box they only cover a fraction of the business process they will still need to be wired together.

EA’s will still have to tie together the following architecture concerns:

  • Business Architecture – Just because the application moves to the cloud it doesn’t mean that business architecture will not occur. With more applications in the cloud there will be new business models emerging as well.
  • Information Architecture – Depending on how these solutions are outsourced you can run into the same challenges enterprises face today but pushed further out to the cloud. As shown below the composite SaaS applications will still need to intercommunicate with each other. I would venture to say that the control of this integration will either be orchestrated solely from the enterprise or will be a hybrid model (which is the most likely) in which based on the specifics of the problem the integration will either occur on the SaaS side or the Enterprise side.

image

  • Communications Architecture – More emphasis will be on communications hardware and the resiliency of it will occur. This will span across into areas such as Operational Management. This will basically tie all the SaaS together for the end user (this greatly depends on what components are pushed out). We can’t assume that there will be only a few SaaS providers but many. So it will be ever important to control this. Devices such as: Network Load Balancers, Web Service and Encryption Acceleration Devices, Security Devices, and the obvious routers and switching hardware. There will be some other opportunities that SaaS providers will be able to provide and that is decentralized access of these applications via many different mechanisms such as wireless.

image

  • Operational Management – With this component it involves architects doing more architecture review types of activities of the SaaS players. PMO activities can perform the standard "check it off the items" but there will still need to be verification of these architectures. Additionally, since these applications will be intercommunicating there needs to be assurance that desired architecture solution fits in a multi-SaaS environment.
  • Security and Risk Management – This will be a big one as shown in all the diagrams there is no guarantee that the authentication and authorization mechanisms will be built in a composite manner. Ideally they will be but the facts are that the far majority of COTS solutions today have proprietary identity stores. It will require architects to figure out the right solutions for identity management, data at rest security, transactional security, and physical security. At the end of the day the enterprise is ultimately accountable for the data stored in a SaaS data center (refer to the Financial Services legislation where FSI’s are legally bound to the implications of an offsite breach no matter what type of contract was defined with the SaaS provider ).

To summarize, these are a few areas on the top of my mind where EA’s are affected by this type of SaaS scenario. As shown below in a very simplistic view we have extended the enterprise to the cloud but complexities still remain. I see no reason why an EA’s role would be greatly different.

image

Now that I went on this rant let’s address the questions directly.

  • If it increases EA effort, are the current “framework” any good in this new model?
    • It increases activities in the domains listed above. Like all frameworks they are a good guide, the good frameworks do not explicitly tell you if the solution should be built, bought or outsourced.
  • If it decreases it EA effort, (and assuming we believe in a world where IT will “shrink its perimeter”) how much do we need to invest in EA?
    • Likewise with the answer above, other domains such as Infrastructure, Development and Database diminish to a smaller degree. But you will still have to worry about the 20%.

 

 

Tags:

Enterprise Architecture Coming of Age?

I was just talking about this today on a thread internally here at MS where we were talking about EA challenges. One person commented saying; "all EA’s do is create documents". I don’t agree with this completely, there are a lot of artifacts built but if you are doing you job right there is a whole lot more going on beside being a MS Word lackey. We need to change behavior such as EA’s just building pretty models, but rather make actionable models.

Reading this article from CBR it shows that EA’s are changing from the older model not just creating word documents and Visio diagrams but are creating business impacting process flows and models that are used to actively underpin strategic initiatives.

Of the 289 enterprise architects that responded, 57% said enterprise architecture is being applied to growth and innovation initiatives.

Check out the article it has some interesting facts from a recent study by Architecture & Governance Magazine.

http://www.businessreviewonline.com/blog/archives/2007/08/enterprise_arch.html

Controlling Complexity in Enterprise Architectures

Yesterday I had a conference call with Roger Sessions at ObjectWatch, Inc. to fill us in on the new methodology he created called Simple Iterative Partitions (SIP). It’s defiantly thought provoking and if you were a mathematics major then you’ll love all the reference back to mathematical theory.

I would be curious on your thoughts on this. I am wondering how these fresh methodologies work in the "wild" (i.e., real world enterprises). As we know with many other things, time will tell.

From what I understand of SIP is it provides a methodology that fit’s into existing EA frameworks that gives EA’s a way to have repeatable process in which to quantify complexities in architectures.

Snippet from the paper:

We commonly implement large, expensive IT projects without any idea whether they are based on a sound architecture or not. Many of these projects fail – often at great cost. Projects fail so frequently because we have no models that define ”good” enterprise architectures.

image

When it comes to enterprise architectures, we believe that "good" is most closely associated with simplicity. Of two otherwise equal architectures, the "better" one is the simpler one. This approach requires us to rethink complexity.

 

See More on ObjectWatch

http://www.objectwatch.com/white_papers.htm

 

Tags: Enterprise Architecture

Presenting at the Microsoft SOA and Business Process Management Conference

image

I will be presenting at this years Microsoft SOA and Business Process Management conference. The conference is held on the Microsoft campus, Oct 29-Nov 2, 2007.

I will speaking about composite applications on the Microsoft platform. I will post details about my presentation at a later time.

Check out all of the information, tracks and registration online: www.MSSOAandBPconference.com

Updated: Bank Teller Composite Architecture

This release adds support for ribbons, form-skinning, various CommandAdapters and UIElements are also added, some of which extend CAB as well as offer basic support for DevExpress controls.

The BankTeller QuickStart application has also been updated to incorporate samples of the new XtraWindowWorkspace and DxMenuItemCommandAdapter.

  • Other changes of note:
  • The file structure of the release has been reorganized so that things are slightly easier to find and consistent
  • The project has been renamed from DevExpress.CompositeUI to CABDevExpress.ExtensionKit (to avoid conflicts with DevExpress’ Project Converter tool)
  • The base namespace has changed from DevExpress.CompositeUI to CABDevExpress (this will break existing code but is copy/paste job to fix)
    CAB dlls are now included as part of the release to allow for easier download-and-compile
  • The code has been cleaned up to some extent, to remove unused includes, unused variables and other anomolies

 

http://www.codeplex.com/CABDevExpress/Release/ProjectReleases.aspx?ReleaseId=6655

 

Tags:

Architecture Modeling – IEEE 1471 has been adopted by ISO

ISO has published ISO/IEC 42010:2007, Systems and software engineering — Recommended practice for architectural description of software-intensive systems. The text of this ISO standard is identical to IEEE 1471:2000, and will serve as basis for the joint ISO and IEEE revision.

The joint revision has several goals:

  • to widen the scope of application from software-intensive systems to general systems architecture (including enterprise architecture);
  • to harmonize with the ISO systems engineering (ISO 15288) and software engineering (ISO 12207) life cycle processes; and
  • to align terms and concepts with other ISO architecture efforts, including RM-ODP (ISO 10746) and GERAM (ISO 15704).

As shown below there are many views to architectures. Many times architects want to create the one ultimate view. This is just unrealistic. The 1471 standard provides a taxonomy to represent these architecture views.

 

At the present time, frameworks are aligning to 1471. TOGAF embraces but does not strictly adhere to ANSI/IEEE Std 1471-2000 terminology. From the horses mouth:

In TOGAF we endeavor to strike a balance between promoting the concepts and terminology of ANSI/IEEE Std 1471-2000 – ensuring that our usage of terms defined by ANSI/IEEE Std 1471-2000 is consistent with the standard – and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership.

Additionally, this can also fit into a mapping of views to the schema of the well-known Zachman Framework.

For more information go to the IEEE 147 site.

IEEE 1471 site

FAQ

 

Tags: