Tuesday, April 25, 2023

 I no longer actively write at this site. Please join me in my continuing discussions at https://valufication.com. See you there!!

Tuesday, June 10, 2014

CAT - A Trust Measurement Tool


I would like to introduce you to CAT – A Trust Measurement Tool now available for FREE in your Windows Store.  CAT, an acronym for Comprehensive Advisory and Trust Index, is a self-improvement tool to measure the level of trust that your customer sponsor has in you as a consultant.  As consultants, we are always trying to get to that “Trusted Advisor” status with our customer for at least three levels of objectives: (1) Individual – Renewability, Billability, etc. (2) Account – pull through of services, devices and software and (3) your employer – long term relationship with the customer, technology partner of choice, etc.

 

The concept behind CAT is explained in the screenshot (taken from the app) below.  Trust is a very complex concept that psychologists have struggled to measure even in a personal sphere (spousal, family, friend relationships).  There is negligible research in the measurement of trust in a business relationship.  After researching this topic for well over a year, I have attempted to quantify this using six different facets: Predictability, Dependability, Faith, Competence, Intention and Communication.  The tool asks you a series of questions that address symptoms of “trustful” behavior and gleans the level of trust based on your responses.

 

The app can be found here:

http://apps.microsoft.com/windows/app/cat-a-trust-measurement-tool/a1b68f8b-310f-445a-9b51-1eb3199d395e

 

Usage Guidelines:

·         I would encourage you to download this app and use it to measure the efficacy of your relationship with your customer.

·         GO through the concept screen (click on the concept link at the bottom of the main screen)

·         GO through the tutorial as you familiarize yourself with the app (again, click on the tutorial link at the bottom of the main screen)

·          Ideally, I would suggest you calibrate yourself using this tool every few weeks and watch as you trend towards a positive and fruitful partnership over time.

·         Use it as a self-improvement tool to improve the “stickiness” of your engagements.

 

While I have significant experience as a consultant/advisor, I certainly do not claim to be an expert.  In that light, I look to you to provide feedback and improve the tool.  I would appreciate if you can provide project specific data (anonymous data, of course) as I beef up the “validity” and “reliability’ of this instrument.

 

Thanks for downloading and using CAT.  Enjoy.
 

Friday, January 3, 2014

Valufication


Before we begin to discuss this subject, it is important to agree on a working definition of value.  Obviously, various definitions of value exist.  In fact, value is such a subjective aspect that more often than not, it is in the eye of the beholder. So what then, is the definition of value?
Merriam-Webster dictionary (Definition of Value, 2014) gives the following definition of value.

1val·ue

noun \ˈval-(ˌ)yü\

: the amount of money that something is worth : the price or cost of something

: something that can be bought for a low or fair price

: usefulness or importance

 
For the purposes of our discussion, let us agree that value is the worth of “something”. When quantified, it can be measured in dollars.  When it is not able to be quantified, value can be measured in terms of the goodwill it generates.  Obviously, we cannot measure goodwill in absolute terms.  But we can certainly measure it in relative terms based on a benchmark of sorts.

Then the next ambguity that we need to resolve is the “something.”  In the context of this discussion, it is an activity or service that is provided to the receiver.

I define "Valufication" as the measurement of value for any activity or service.  The value can be either:
·        Quantifiable: The amount of dollars that can be exchanged in return for an activity or service.

·       Intangible:  The amount of goodwill that is generated as a result of an activity.  From a consumerization perspective, it is expected that all goodwill will result in something tangible for the value creator.  For instance, better customer relationship will result in increased business in the future.

Stay tuned for more on this subject....

Monday, November 28, 2011

Role of IT in a Community College

With the advent of social networking and Web 2.0, the role of information technology is no longer restricted to transacting business operations of an enterprise. Customers demand and expect instantaneous information to be made available to them. In the case of a community college with a typically young and energetic student body, registration information, course material, course schedules, wait lists, facilities management, etc. all need to be inter-connected and available to the them by demand. “Distance learning” was an innovative concept fifteen years ago and a “nice to have” supplement to traditional methods of lecture delivery. With today’s rapid proliferation of network bandwidth, “online learning” is a necessity which an educational institution cannot do without. In light of these contexts, it is important that the CIO recognizes the need for an easily accessible, highly available and yet highly secure environment.



The essential paradigm of knowledge assimilation has changed from traditional note-taking and a one-sided lecture emanating from the podium to a more dynamic and vibrant environment even inside a live classroom. As long as it not disruptive, students ought to be encouraged to participate actively in class using laptops, iPads and other “gizmo-de-jour” that are connected to the internet. This way, they can contribute meaningfully to the discussions by carrying parallel research using powerful search engines that were all but non-existent even fifteen years ago. The student body of today has essentially mastered the art of multi-tasking and it may be unreasonable to expect them to be disconnected during the period of the lecture. Given the need for constant connectivity, it is imperative that such an ambience is provided by the college. If not, you can expect to see dwindling numbers in new registrants.



The enriched learning experience that technology providers comes at a cost. Projects, presentations and other requirements of a typical class are now more creative demanding the need for more resources in terms of network bandwidth, storage, computer power, etc. Unfortunately, this demand is not uniform but certainly peaks during “finals” week every semester/quarter. Should the college then look for a dynamic need-based solution as opposed to investing scarce resources in information technology that may otherwise lie unutilized? The answer is a resounding yes. Cloud computing and service oriented architectures today are able to provide a need-based dynamic provisioning essentially optimizing the demand-supply curve.



Another factor that works in the favor of a cloud computing architecture (or more specifically, software as a service - SAAS) in learning institutions is "technology obsolescence.” With the rising cost of education coupled with an uncertain employment prospects, it is fair to expect students to demand that the latest versions in software and operating systems are made available to them. In this situation, it is unwise for the administration to invest heavily in licenses for software/hardware when they are likely to become obsolete by the time it is fully deployed.



Added to all of this is the ubiquitous need for IT to be constantly aligned with the business. In this case, it is the business of education. As administrators devise new strategies to increase enrollment and keep pace with the competition, it is not enough for IT to merely provide a supporting role. On the contrary, IT needs to be an enabler for newer ideas and promote both disruptive and non-disruptive paradigm shifts in the education field.

Thursday, October 20, 2011

Applications 2020: Social, Mobile, Gaming and Collaboration Impact on Your Portfolio

In this session, the presenters attempted to look at two key issues:




1. What is the user perspective of software applications in the year 2020 and what actions are necessary to deliver on these expectations?

2. How must application strategy and governance change to move to the world of applications in 2020?



In this day and age of heavy consumerization and multiple device ownership, having an ensemble experience in that all devices need to work seamlessly together is a critical requirement of applications.



Given the proliferation of multiple devices, it is but natural that users would have a short attention span. Hence, the presenters suggest using "gamification" as a strategy to build interactive game features that will encourage participation and challenge.



But mainly, they caution that the next breed of developers need to be trained in human factor design and hybrid thinking. The developers need to expect additional interaction types an be prepared to offer "on the fly" analytics to change user experience dynamically.

Wednesday, October 19, 2011

The business impact of social, management and technology trends

This morning session by Jackie Flynn at the Gartner IT Expo on the major societal management and technical disruptive trends and its impact on organizations was a pretty interesting and useful indeed. She began by talking about the current hot trends that occupy our attention. These are, for example, F-commerce, enterprise app stores, big data, 802.11ad, gamification, group buying, cloud bursting, natural language question answering, behavioral gestural analytics, social TV, micro insurance, image recognition, personal cloud, 3-D bio printing, etc. She did a very good job of separating these disruptive trends into three major groups: societal, management, and technical.

At the outset, she talked about megatrends that are pervading these three areas. At a high-level, these are global and distributed, open and transparent, always on and instantly accessible, contextual and right sized and finally social and mobile themes. Corresponding to these megatrends were mega-capabilities that were discussed. These were in the area of capturing new info, exposing new patterns, and delivering just in time insight and access.

She looked at each of these trends from three perspectives: the factors driving the trend, the social impact and the business opportunities generated as a result.

I do not want to give you the complete discussion of each of these trends as a simply do not have the bandwidth to talk about it at length. However I will say this: businesses need to look at the information that they have and use it to identify trends way before the market does. They need to re-evaluate the role that information plays in their current corporate strategy.

Tuesday, October 18, 2011

Ten Steps to Building Private Cloud Services - II

As promised, here are the ten steps to an effective private cloud strategy:

Effective Leadership: From vision to execution, getting buy-in from various stakeholders and alignment with the business, clearing hurdles and driving cultural change.
Definition of Services: What are the services that are provided, their required SLAs and the current SLAs. Determine service costs and their required skills.
Evaluation of Alternatives: Is moving to the cloud the right approach? Generally speaking, non-standard and customized systems are not suitable in the cloud.
Creation of Metrics: Metrics of economics, quality and agility of service need to be created both from an IT operations as well as a service user's perspective.
Development of business case: In a recent survey at the Gartner DC conference, 55% of respondents thought agility/speed is the main driver to move into a private cloud. Only 21% responded that cost was a main driver.
Development of people plan: Communications, organizational structure, career paths, performance evaluations are necessary components of the people plan.
Development of business management plan: Strategy and planning of the move, funding model, service development, reporting etc. are main components of the business management plan.
Development of technology plan: Investment protection, fabric selection (compute, storage, network, etc.), vendor partnerships, interoperability aspects need to be addressed in this plan.
Development of operational process plan: DevOps and cloud computing model, dynamic operations, customized services are major components of this plan.
Start small, think big: Build-in learning and proactive expansion into the equation.

As I mentioned earlier, these are nothing new. But nevertheless, it serves as a good checklist when developing a private cloud migration strategy.

Ten Steps to Building Private Cloud Services I

Thomas Bittman presents a decent view on the steps required to build private cloud services. However, it is just that. For those who have been "in the cloud" for a while, it is nothing new or earth shattering.

While the ten steps are nothing new (presented in the following blog post), he does present an interesting approach to migration to the cloud. He presents a five staged approach:

Stage 1 begins with Server Virtualization where the primary advantages lie in consolidation and reduction of capital expense.

Stage 2 is distributed virtualization where flexibility and speed of operations with reduced downtime are touted as main advantages.

Stage 3 is the migration to a Private cloud where the concepts of self-serve agility, standardization, usage metering and "IT as a business" are emphasized.

Stage 4 is the migration to the Hybrid cloud which is useful in reducing costs and increasing flexibility for peak loads. Think "annual benefits enrollment" of HR as an example.

Stage 5 is the ultimate move to Public cloud with the eventual elimination of capital expense and total flexibility. However, not all enterprises are suitable to move into a public cloud.

While I agree with the first three stages and maybe stage 4, I am not sure stage 5 is right for all enterprises. Not withstanding compliance or regulatory constraints, assuming all enterprises are suitable to move into a public cloud is a mistake.

The next blog on this topic will detail the ten steps to building private cloud services

Creative Destruction...Huh?

The most common interpretation of this phrase is in the domain of economics through innovation and progress. For example, pruning a company's assets to remain nimble and agile in an ever-competitive marketplace.

I will attempt to put a different spin to this phrase. It is another form of the "Survival of the Fittest" mantra. A herd of antelopes survive in the wild by naturally pruning the weak and the infirm. By doing this, they ensure the continued existence of the species while sacrificing a few for the "greater good" of the herd. So also in business (I suppose in life as well), the "greater good" must trump the immediate but short-lived positives one expects as a result of any premeditated action.

While most businesses today lock in 70% of their resources in ensuring reliability, they find themselves easy target for competition. Business solutions need not be predictive and staid all the time just to avoid risk. At the same time, you should not have a totally innovative and dynamic solution that is not grounded in any reality. One way of ensuring an innovative and dynamic enterprise is for the organization to look at creative ways of keping the organization nimble at a manageable level of risk. Embedded therein is the concept of "creative destruction".
In explaining creative destruction, Gartner analyst Tina Nunno speaks about not thinking in a binary world but more in an analog terms. Think about it. It does make sense. When was the last time that a decision of any significance that you made was a pure black or white decision? Most likely, you agonized over several alternatives each with its own shade of grey. Examples of constrained binary thinking typically found in business are:

IT vs Business
Control vs Chaos
Leader vs Follower
Supply vs Demand
Build vs Buy

Following along similar lines, she goes on to say that creative destruction can be achieved by using a "Pace layered application strategy" wherein systems are categorized into:
Systems of innovation: Systems driving innovation
Systems of differentiation: Systems that help the organization differentiate in the marketplace
Systems of Record: Record-keeping systems

Separating the organization's systems into these areas enables simplistic systems through creative destruction. In the end, it essentially boils down to the organization's "Appetite for Risk".

Top Technology Trends of 2012

At one of the gartner sessions, here are the top technology trends identified for 2012:

1. Media Tablets and Beyond
2. Mobile-centric apps and interfaces
3. Contextual and social user experience
4. Internet of things
5. App stores and market places
6. Next generation analytics
7. Big data
8. In memory computing
9. Extreme low-energy servers
10. Cloud computing

Microsoft vs. Google vs. Apple

Interesting session this morning comparing Microsoft, Google and Apple on their philosophy and approach to business.

The thoughts reproduced below are entirely that of the presenters and not my own. I wanted to present an unadulterated version of their version. When colored with my commentary, I indicated it as such.

If you were to hear the presentation live, one gets the perception that the presenters are trying hard to make the impression that Apple is the company "to be" in today's competitive market.

Nevertheless, the presenters make some interesting comparisons on these three organizations:

First of all, Apple is presented as a vertically integrated high margin hardware provider whose emphasis is more on elegant design rather than low cost.

Google is presented as essentially an advertising company to all the world's people which uses the power of engineering to develop geeky applications with mass following.

Microsoft, on the other hand is presented as a software and platform system developer which has its own ecosystem to help thrive the Microsoft brand.

An interesting comparison that was made between Google and Microsoft in their sustainability models. Google was painted as a cowboy who believes in the democratization of information. Google believes in capturing the next 2 billion users and lacks little or no enterprise focus. They are considered as radical innovators who deny anyone the opportunity to control their destiny.

Microsoft was painted as a steady entity that believes in the democratization of technology. On the other hand, Microsoft has a strategy of an orderly enterprise growth which defines and develops programming platforms. Microsoft is persistent who is no longer the innovator but believes in leap-frogging and making better the innovations of others.

More on this later….

Monday, October 17, 2011

Opening Keynote at Gartner Symposium

The focus of the opening keynote was themed along the key aspects of Cloud, Social, Information and Mobile computing.

These four key areas together form a nexus of forces which makes any and all recent architectures immediately obsolete. The information technology paradigm is easily overshadowed by Information Ecology.
However, all of this comes at a great risk. In fact, most disruptive technologies come with significant risks that needs to be appropriately harnessed into a risk adjusted value management. It belies the oft-held belief that risk management in the face of constant disruption is a waste of time.

The keynote was structured around 3 themes:
Post-Modern Business
Simplicity
Creative Destruction

Peter Sonnengard clearly outlined that companies that use leading risk indicators clearly outperform their competitors. The reality, of course, is that in today's dire economic climate, it is easier said than done. The forecast for overall IT spend is predicted to be just under 4% through 2015. This outlook is made by Gartner after factoring the continued sluggish growth of the economy.

Daryl Plummer went on to talk about post-modern Business. So what really is post-modern business? It is an "anything goes" approach that focuses on deeper relationship with customers, suppliers and partners. It is a business "with no walls" mantra where you rely on delighting customers, garnering the interest of disengaged customers and combating their short attention span.

Hung Lehong talked about simplicity as a paradigm in today's way of doing business. By 2015, four mobile apps will be deployed for every single traditional PC based application. This necessitates a basic "rethink" in developing systems that are context aware and people centric resulting in a rich user experience.

Tina Nunno closed out the keynote by speaking about creative destruction. For those of us not in the know, it is a controlled rationalization of existing IT and Business assets in the hopes of a leaner and meaner organizational system. Therefore, every IT and business executive should evaluate their own appetite for risk. This will facilitate that technology does not create limits but actually facilitates the lowering of barriers.

All good points which made for an effective keynote.

Gartner IT Symposium 2011 at Orlando

First blog in a while. Wasnt sure what the policy of the new company that I joined. Excellent company BTW. Made a good choice. Now on to bigger and better topics.

This week, I am at the Gartner IT Symposium in Orlando. Between sessions, I will be trying to report on the day's events as seen through my lens. If you want me to cover a particular topic, please tweet @sree_sundaram. I will do my best to accomodate your request.

Waiting for the keynote to commence.

More to come later. Ciao

Tuesday, December 22, 2009

Developing EA in the context of managed services

This article first appeared in ebizq and is being reproduced here:

When practitioners refer to examples of Enterprise Architecture (EA) programs, they generally refer to in-house initiatives run by a business’s IT department. Therefore, the objectives of such programs are grounded in the business’ self interests. In the case of Managed Service Providers (MSP), who not only run their own enterprises but also the IT departments of their customers, the objectives are dual and sometimes competing. In this article, I attempt to differentiate between these two kinds of EA programs and look at ways in which an MSP can not only help themselves, but also their customers. First, let me begin at the beginning by defining EA and MSP.

Different experts give different answers in defining enterprise architecture. But there a number of commonalities in their definitions. There are technology and business architecture components that are the backbone of most frameworks. There is also a strong information architecture component in some of the more practical frameworks. In the interest of brevity, I will quote only one definition from Gartner, which defines EA as:
Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.

An MSP, for the purposes of this discussion, is defined as a provider who provides services (both delivery and management) in the areas of network, server management, application maintenance, infrastructure maintenance, and hosting. A total service provider usually contracts for a Walk-In-Take-Over (WITO) type of an arrangement.

Today, EA services are generally provided by the IT department (the discussion of the wisdom of this is a subject of another article.) An enterprise architect program typically reports directly to the CTO/CIO and is headed by a senior enterprise architect. The function of this group is to understand the business, facilitate the alignment of IT with the business, and ensure that IT services are provided to support both the tactical and strategic operations of the business. As part of its mandate, the EA provides policies, standards for maintenance operations, and guidance for adopting new and emerging technologies.

This works well when you have an IT budget of sufficient size and--more importantly--the people to help implement the EA program. But what happens when the CIO decides to totally outsource IT operations to an MSP? Who runs the EA program when you have little or no influence on the technology component? While the CIO might still retain key people to interface with the MSP and the business, it is usually not an effective arrangement.

Contrast this with the EA program of the MSP. It is a dual objective program in that it needs to serve both its business and the business of its customers. This requires the creation of two charters; one internal and the other for its customers. It may look and feel like a duplicate program, one where every deliverable seems to come in two flavors – internal and external. The reality, however, is that for a program to be effective and practical, the MSP needs to have a generally common EA program that is applicable to both its internal and external customers. There may be minor tweaks here and there but the net intent and direction of the program should remain the same. (Note that this does not apply to the governance structure of the EA program, as it is something that should be tailored specifically to each customer).

To practically develop the EA program in a Managed Services scenario, it should be led by a chief enterprise architect with a number of enterprise architects reporting to her. This pool of EA will ideally come from backgrounds with vertical strengths (i.e. energy, healthcare, insurance, biotech, automotive, etc.) Each of these EA’s are then assigned to one or more (ideally two) customers in the same vertical. By rotation or otherwise, a similar pool of EA’s can develop the internal institutional capital of the MSP EA program. These artifacts/knowledge capitals are then filtered down to the customer level with the appropriate tweaks to maintain relevance and suitability.

While implementing such an EA program is not all that difficult, the issue is convincing the end customers of the sincerity of the MSP’s EA services. The typical contact point in an MSP relationship is between the account executive of the MSP and the delivery head/CTO of the customer. It is a challenge for the MSP to get beyond this relationship and gain access to the business side of the customers. Generally, there are two reasons for this: one is that the customer’s IT head feels the need to act as a go-between the business and the MSP to ensure continued relevance of their position (essentially job security); two is that the customer’s IT is in a better position to understand its business than the MSP (vertical/domain comprehension). While these may be valid reasons, the customer would actually gain from allowing access to the MSP enterprise architect. This person would likely have had experience in similar domains and can bring a great deal to the table in terms of process efficiencies, identifying deficiencies in information systems, and recommending optimization strategies.

To illustrate my point, I offer two case studies. In the first case, the MSP recently established a contracting relationship with a customer who recently divested from its parent company. As is usually the case, the relationship between the recently-divorced parent and the new entity was acrimonious. Being a nascent company, the customer was initially unwilling to let the MSP communicate with the divorced parent. Therefore the MSP initially stayed out of the contentious issues and let the customer lead through these technical discussions. Since this was a new experience for the customer, they did not ask the right questions and anticipate issues before they arose. These management errors led to cost overruns and project delays. In desperation, they finally asked the MSP to take a more active role in managing the relationship. The result is that the MSP was soon able to get things going in the right direction. These and other value-added services provided by the MSP above and beyond the contractual obligations, eventually gained the trust of the customer who then asked that the MSP EA sit in on strategic meetings between the business and IT of the customer.

In another case, the issue concerned a well-architected but poorly executed project. As in the previous case, the MSP had no access to the business partner of the customer. Again, by stepping up to the issue and taking the responsibility to rectify the project, the MSP gained the trust of the customer’s IT department. The MSP certainly generated additional business because of this project. But overall, the relationship improved significantly, due to an effective inclusion of the MSP in the business-IT strategy meetings of the customer.

As these examples indicate, it is always in the interest of the MSP to provide the value-added services to any ITO relationship. Merely serving the letter of the contractual arrangement does not establish a long and fruitful relationship with the customer. At the same time, customers need to realize that it is in their best interest to engage MSP earlier in the contract to help them make sound strategic technology and business decisions.

Monday, June 29, 2009

Interdisciplinary Design as an Instructional Discipline

I was invited to speak on a panel discussion entitled “Interdisciplinary Design as an Instructional Discipline” at the National Science Foundation (NSF) Engineering Research and Innovation Conference in Honolulu, Hawaii. The theme of the workshop was to foster creativity and innovation in approaches to design by including it as an instructional discipline in academic institutions. Therefore, panelists and invited audience from diverse backgrounds such as architecture, business, product design, information systems, etc. were engaged to provide their perspectives on the design process. The discussion, led by senior industry decision makers from Siemens, Honeywell, PetSmart and Dansk, provided an interesting perspective on issues and challenges facing today’s global and economically turbulent marketplace.

It was interesting to note how the process of design is conducted in disciplines other than information systems and software engineering. There were quite a few commonalities but then there were obvious differences as well. Almost all of the fields do have a multi-step process consisting of conceptual, logical, and physical designs. The difference lies in the interpretation of what constitutes each of these design sub-processes.

I will not elucidate on the design issues that were pertinent to other areas but I will be remiss if I do not highlight the design issues facing our industry today:

We need a design process that consistently facilitates the alignment of the implemented systems with the intent of business. Despite our best effort in trying to come up with a workable design, the rate of failure of IT systems (maybe not systemic failure but nevertheless significant failure) today is quite high. Why is that so? Is it because we err in gathering, analyzing, and/or comprehending the requirements of our business partners? Or is it that our design process is flawed that we fail to realize our system deficiencies well in advance of implementation.

How do we ensure integration in terms of business rules, standards, information flow, process flow, interoperability, etc. across the enterprise? Today, it is not uncommon for businesses to be spread across a much wider geographical and cultural spectrum. Consequently, the varied nature of our system boundaries poses a much greater challenge in integrating our process flows. Could we adjust our design process to take into account these seemingly extraneous factors?

How do we facilitate easy change with the ability to quickly react to market? With the advent of the information age, the market is a much more dynamic entity today when compared to a time twenty years ago. Therefore, not only does our design processes need to be sound but they also need to facilitate a quick entry to market. As the market conditions are forever changing, the design process also needs to be flexible to optimize systems development and maintenance.

How do we ensure all of the above and yet keep pace with increasing technology and programming paradigm sophistication? Adding to the other challenges, the constantly changing technology landscape with increased sophistication in technology paradigms sometimes provide a disruptive influence that needs to be countered to ensure a stable software development process. We can, and should, embrace these new developments but certainly not at the cost of disrupting the enterprise. We are here, after all, to serve the business and no amount of tectonic paradigm shifts should alter our basic focus: supporting the enterprise.

Can we perhaps incubate these ideas into future generations of software designers if academic institutions were to encompass them into a design instructional discipline? Or should such things be learned experientially rather than being advocated in a formal instructional setting?

On the long flight back home, it certainly made me go, “Hmm”.

Friday, May 8, 2009

"Architecting the Enterprise", a panel discussion at DESRIST 2009

I was invited to speak on a panel discussion entitled “Architecting the Enterprise” at DESRIST 2009 (a conference for design researchers) and thought I would share my thoughts on what this community thinks about Enterprise Architecture. But before we begin, what exactly is design research? Simply put, design research investigates the process of designing in all its many fields. It is not the research of the end design.


The discussion was primarily led by enterprise architects from Siemens, Pricewaterhouse Coopers, AT&T, Open Group Architecture and moderated by Penn State U. It was a useful discussion which brought forth the following:

  • It continues to have a heavy technology slant with little attention being paid to the business aspect of things.
  • Little or no attention is paid to the informational/data needs associated with a successful EA program.
  • The academic community can help in this regard by providing a realistic definition and value of EA in both business school and computer science curricula.
  • In most organizations, any senior technical architect with a good knowledge of the business is considered an EA. Why? Because he/she has the ability to understand the domain (not the business, mind you; these are two different things) and still talk technese. And then management wonders why there is no business-IT alignment.
  • Most EA in most organizations probably do not know about the various architectural frameworks much less know the difference. Like I said earlier, most are techies with a sound domain (not business) knowledge.

    Sobering thoughts, eh?

Wednesday, April 15, 2009

Keeping EA realistic?

Your organization has chartered you with developing a nascent EA program. You gleefully rub your hands and proceed to get to work. First comes the nebulous, then the specifics and then hopefully the applications of the specifics. As you diligently move from one phase, it is very easy to get carried away and look for perfection at every stage. So how do you make sure it is all relevant from your organization’s perspective?


If you take a look at all of the wonderful frameworks that abound the literature today, these are all well thought out and require significant amount of investment both in time, effort and cost. But in reality, are most corporations willing to spend the time and effort to go through a rigorous exercise of aligning/developing to these frameworks?


Sure, some of them will. These are usually organizations for whom process, standardization, precision are necessary aspects of their domain and are most likely in the aerospace, defense, nuclear fields. But for the typical for-profit business entity who can live with a degree of variability in their product offering/service, investing in developing or adapting an enterprise architecture framework is something that they can always put off until next year.


Then, what is the solution. Keep it simple, realistic and always practitioner oriented. Be ready to show ROI at every stage of the game. Keep your value propositions specific and quantifiable as much as possible. In the coming days, I am going to introduce a framework which purports to do just the same. It is called SEAM™.


SEAM™ stands for Simple Enterprise Architecture Management.

Stay tuned.

Tuesday, February 17, 2009

A simple methodology for measurement of baseline performance

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.
- Lord Kelvin



I. Introduction:


Every so often, businesses ask their IT counterparts very general questions on the capacity of their current IT infrastructure especially as it relates to customer facing applications. While these questions are very vague, they nevertheless require a diligence on the part of the IT manager to get the answers. Since these questions come with a reasonable periodicity, it is prudent for the IT manager to devise a measurement strategy to baseline the capacity of IT assets. Quite a few IT managers think that creating a baseline is an expensive proposition requiring the services of high-end consultants from a top-notch consulting firm. Nothing could be further from the truth. There are simple and commonsensical ways to get the baseline measurements done. In this post, I discuss a simple and generalized methodology for measuring the baseline performance of IT infrastructure within an organization.

Developing a measurement baseline is usually the first phase of a performance analysis and optimization plan. This is akin to assessing the current state of affairs. As I have often said, “you cannot optimize if you do not know your current capability”. Therefore, the intent of creating a measurement baseline is to develop a benchmark of current usage for both hardware and software resources. Once you have a benchmark, one can then carry out additional performance analysis to determine optimum configuration and response times for various scenarios. That, of course, is a future topic for discussion.

II. Procedure:


At a high level, the following steps are required to develop a measurement baseline:



  1. Identify resources that need to be used and determine the type of role/work performed by each of the resources.

  2. Determine the workload characterization.

  3. Select appropriate objects and their associated counters for measuring performance.

  4. Automate data collection by creating logging schedules and upload data into a suitable format for subsequent analysis.

  5. Sample the data at the appropriate intervals.

  6. Generate descriptive statistics and line graphs to identify peaks and valleys of system usage.

  7. Present the findings using a format relevant to the discussions.



The following sections detail each of the above steps:



  1. Identify resources and Roles: An accurate measurement baseline of current use can only be developed by monitoring resources that are currently used to host software applications. The right approach is to use passive monitors on resources that are part of the current production configuration. Care must be taken not to disrupt your steady state of operations.

  2. Workload Characterization: The next task is to determine the characterization of the infrastructure workload by studying your clustering and load-balancing heuristics. Obviously, primary servers will have a greater hit ratio when compared to secondary servers. Understanding the topology of the environment is a key to an accurate analysis of current usage.

  3. Selection of Performance Counters: The advantage of most applications in today’s environment is that they are instrumented off the shelf. This means that the administrator rarely has to devise software widgets to accurately measure the performance of these applications. However, the success of an accurate baseline is indicated by the right selection of these performance counters. A selection of too many counters will yield a data overload which makes it very cumbersome to analyze using standard methods. On the other hand, selection of too few counters makes the point of the whole endeavor meaningless. A good and experienced administrator should be able to pick and choose the right mix of these counters.

  4. Data Collection: Automate the collection of data as much as possible. In all of the standard operating system environments, provision exists to automatically collect periodic data points and store them in text files. These text files can later be imported into spreadsheets or databases for the actual analysis. Periodically check to ensure that the data is indeed being collected and stored appropriately. It is also important to have these raw data files appropriately named with the date and time of the log data for easier stratification later. Failure to do so will almost surely lead to confusion and possibly erroneous conclusions.

  5. Sampling Period: Once you have the basic data collection framework in place, it is important to choose the correct sampling period. It is critical that the sampling period encompasses any cyclical nature of the business. For instance, there may be a heavy volume of transactions during the first Monday of the month or the last Friday of the month. Or it could be that the pattern of usage is different for each day of the week. To complicate matters further, there also may be different usage patterns during different times during the day.

  6. Descriptive Statistics: Decide on the descriptive statistics that are intended to be used for data analysis. It is important not to go overboard with your analysis unless it is a complex real-time trading system where every transaction is critical to the business success of the enterprise. For the most part, summary statistics such as mean, median and mode supplemented by basic “normal” analysis such as the standard deviation, confidence levels, etc. are generally sufficient.

  7. Presentation: All of the analysis will be for naught if one is not able to convince the decision makers on the accuracy and relevance of your findings. Therefore, use simple trend graphs, histograms, Pareto charts, and pie charts to convert the analyzed data into meaningful information.

The seven steps discussed above is a simple process that can be carried out with minimal costs. Almost organizations have access to some sort of spreadsheet software, desktop database software and rudimentary presentation and graphing software. The creation of a measurement framework for the first time will probably require some investments in terms of thinking through the process. Once the measurements are validated, calibration of the framework is usually straightforward and much less cumbersome.

Friday, February 6, 2009

Components of a compelling technology roadmap

So what are we looking for in a technology roadmap? A good technology roadmap begins with the business side of things. There is no point in talking about changing technology simply for the sake of changing things. There is of course the “cool” factor of playing around with the latest and greatest. But then, mention that to any half-sane CEO and I would be surprised if you are not kicked out of the office.

Therefore, let me begin with the components of a good technology roadmap. Obviously, there is the perfunctory introduction detailing some background information. Once you get past that, you will need to define the scope of the expected change. You will also need to explain what the organization can expect to get out of implementing the roadmap.

A well documented roadmap will have a clearly defined section of business drivers. What is driving the business to ask for change? Is the technology antiquated and not able to satisfy the business need? Has the business significantly changed so that the technology assumptions made earlier are no longer valid? These and other questions will need to be answered in the roadmap.

Next come the technical drivers that are driving the roadmap. It could be that there is a significant paradigm shift that necessitates a complete overhaul of the technology inventory. It could also be that most of the infrastructure is so significantly outdated or out of warranty that it makes financial sense to look at a complete refreshment of infrastructure.

Closely related to the technical drivers are the technology enablers that compel a strong argument for change. For instance, if the company’s model has moved from a “brick and mortar model” to a “click, brick and mortar” model, then it makes sense to look at infrastructure in the form of web servers, application servers, firewalls, load balancers, etc.

A good roadmap has a clear section assessing the current state of affairs. If you do not know what you have, then you do not know what you lack. With the rapid proliferation of dynamic discovery and probing tools, it is usually a matter of setting up auto-probes that do most of the work for you. Once you have the current state well assessed, focus on the vision of desired state both from a business as well as from a technical perspective.

The gap analysis between the current state and the desired state of the enterprise will form the basis for a cost benefit model. I can assure you no senior executive will consider your request seriously if your roadmap does not include a solid cost benefit analysis.

Of course, no roadmap is complete without including the timeline of proposed change, the resources needed to accomplish the task and other mundane administrivia.

Having a well laid out technology roadmap provides many advantages. Not only does it force you to think of things in a structured fashion, it also provides a compelling case to the folks holding the purse strings.

Thursday, January 29, 2009

I don't get no respect...

So I walk into a conference room full of design engineers and project managers the other day and get a bunch of dirty looks from them. These looks probably meant:

Who is this guy?
What is he doing here?
Who invited him?
Here we go again (sigh)
Ah, here comes the trouble maker (extended sigh)

You enterprise architects out there probably know what I am talking about. I am sure you have encountered situations where you had to repeatedly explain your role in the project. Most design engineers probably never heard of you and developers, even less. The other senior managers/directors (usually your peers, really) probably think of you as another highly paid architect and so expect you to attend to the technical minutiae of every aspect of the project.

Levity aside, the role of an enterprise architect is rarely perceived clearly. To adapt an oft-quoted idiom, “He/she is all things to some people and some things to all people”. Your immediate boss and probably the boss’s boss (the guys who hold your purse strings) probably know what your role is and where you fit into the organization. If they do not, then “Gawd help you”.

So how do you fix this problem? Here are five suggestions:

First, with the help of your boss (and your boss’s boss), put on a road show. Create a reasonably slick PowerPoint (Flash is even better) presentation. Take every opportunity within (and outside) the organization to showcase your abilities, your role and how you are here to help them. Tell them what you can and cannot do, what you will and will not do.

Second, establish your credibility. Always be prepared for your meetings. It is okay to ask basic questions but ensure that the intent of your questions is well understood. Other folks attending the meeting who were hesitant to ask the basic questions may now “cotton on” on to your intentions.

Third, lead “brown bag” lunch discussions on important technical and business topics relevant to your organization. To ensure participation (at least initially) provide free lunch. Believe me; a free lunch would get them in droves. Slowly, but surely, you will see your investments in time and effort paying off.

Fourth, insert yourself into as many meaningful projects or discussions. The earlier in the project cycle, the better it is for your cause. This requires some diligence on your part to get into discussions that may end up nowhere. But then, it at least adds to your visibility.

Finally, produce as many artifacts as you can to help the cause of your fellow architects or engineers. No one likes to be sermonized from a pulpit. If you can supplement your ideas with artifacts from your previous job experiences (obviously scrubbed and sanitized for your own protection), it will help to establish you as a person with substance.

These five suggestions have been used by me in the past and I continue to use them even today. Remember, having the best wares does not guarantee that it will be sold. It is marketing these wares that make the difference.

About Me

My photo
Sree Sundaram is currently a Sr. Director of Enterprise Architecture at a major global technology firm. He is currently engaged at two major international biotechnology firms in optimization and migration of infrastructure from their current platform to a newer technological platform that is in line with their current and future business needs. Sree has solid experience in understanding the needs of both middle and top level management and has the ability to communicate at both levels. He is fundamentally aware that the transactional and short-term needs of middle level management are different from the long-term vision of top-level management. He has successfully dealt with such issues by providing an IT framework that meets both the short term and long term needs. In general, Sree helps to prioritize competing initiatives using a combination of his acumen, communication skills, strategic and operation plans.