Showing posts from 2008

Doing a lot more with a lot less in the current environment

Given the current market conditions all business executives are once again challenging the technology teams to do a lot more with lot less. Following are some of my thoughts around this (nothing new - just going back to the basics).
Focus on solving your customers needs - independent of the industry. Do not scale back on innovation. All markets typically are different when they come out of a recession that what they were before one. It is only those who focus on innovation shall come out as winners.Focus on your core business - differ the adjacent market until the market recovers (unless it is related to the innovation)Do not focus on developing new infrastructure (unless absolutely needed). Build out the infrastructure incrementally as new products and offerings are either upgraded and rolled out to customers.Do invest heavily on large packaged applications. As the entire market is going through a shift - it may not be wise to invest in large packaged applications. It will consume a l…

Key Learning from reclycling

Over the long weekend I decided to recycle all the boxes that were in my garage and following were my observations:
I had not recycled the boxed for a very long time - so it was complete mess in the garage.About a decade back you could just put the boxed out and the garbage collectors would take it for recycling - not any more. We now need to break down the boxes - flatten them and stack them in the provided container in a systematic manner - otherwise they WILL leave them behind.As I was breaking down the boxed - realized that the technology has changed. It is very easy to flatten and stack them.However, there were a couple of boxes where I need to use brute force, cut them and even stand on them to forcefully flatten them. Some of them were recentely manufactured ones - guess they did not use the latest technologyThese days - eveything seems to come in box, no matter what you buy. It is important to recycle the boxed on a weekly basis - instead of waiting for a long time. The lon…

Architecture Organization Patterns

Over the past couple of years I have observed that companies from the high-tech industry are adopting two distinct patterns for organizing their architecture team.

Centralized Organization:
This is true for most IT organizations led by a CTO-IT, VP EA or Chief Enterprise ArchitectAll EA members reports to the head of the EA teamIndividual EA are either focused on some core technology, IT functions (such as networks and operations) and Business DomainBusiness Domain Architects dotted line report the head of LOB-IT (typically the Divisional CIO)LOB-IT may also have Architects who dotted line report to the member of the EA teamAs IT organizations need to focus on what is best for the enterprise - rather than on individual business units, this is a preferred organization structure adopted by IT organizations.

Federated Organization:
Most of the High-Tech companies have adopted this model for their line business (with IT adopting the Centralized Organization)
Typically there is a Chief Architec…

Comparing Current Financial Crisis to SOA - Continued

I agree completely with Yogish's views as posted on "Comparing Current Financial Crisis to SOA" and his advice on treading light and having solid justification prior to undertaking SOA style projects.

A) An upfront investment has to be made in performing the right level of business process analysis and business architecture to pick the right SOA service candidates.

B) One should not attempt embarking on SOA with a highly visible project, as these types of projects operate under unwarranted pressure for delivery and with little patience for "architectural constructs" SOA or otherwise!!

C) Any project that is a high return type process with established KPIs and benchmarks is a good candidate for first time SOA implementations. Here gains are measurable (in the form of cost avoidance, cost reduction etc.) and can be directly tied to SOA-enabling these operational processes.

D) One has to invest in marketing the success of these projects and the services that were res…

Comparing current financial crisis to SOA

Comparing the current financial crisis with SOA was one of the topics we briefly discussed at the Community of Practice working group of the SOA Consortium. Following are some of my thoughts on this topic:
The current financial crisis is based on a flawed foundation - the sub-prime mortgagesInvestment bankers and mortgage companies composed new and complex derivatives and resold them all across the globe - all in the name of new and investment modelsMost of the executives of the involved companies as well as government agencies reviewed some of the aspect of the new world and based on what they knew then - thought it was all OK.No one seriously took time to review the potential business risk and take corrective action before it was too lateThe investments were so interdependent which made it impossible to understand the implications or the impact of letting one service fail. Example: The is no rational on why Lehman Brother was allowed to fail? and why AIG was rescued? ...and we see th…

Canonical Models and Services

In thinking about canonical models one mostly thinks about an enterprise worthy or industry compliant representation of a business concept or a business entity। Often this canonical model compliant payload is packaged in a response envelope that is returned by the service provider. However, the question is whether the term canonical model can be used to define the " business request" or if it is limited to the "business response". This blog explores the canonical request models that might be used to alter the behavior of enterprise services using search services as an example.
Let us look at a "search service" where one could think of a "context based search request" that is made to the search facility to make the search behavior of the service providers more efficient। In addition, this "search context" could also be used to express the specific search needs of the service consumer. Given this, the question is whether the canonical mod…

Organization Skills assessment and Reference Architecture

The other day I was participating in the engineering skills assessment discussion and it dawned on me that mapping the skills to a reference architecture makes is much easier and simpler discussion to have. The reference architecture enabled us to first list the categories and drill into each of them to define the skills as well as leveling required for Architects, Developers, QA and Managers positions.

Key Learning's:
Having a reference architecture also helps in organization (engineering) skills assessment The Skills Assessment / Mapping is independent of Governance and Organization. However, Governance drive where these resources belong

SOA Consortium announces SOA Case Study Winners

The SOA Consortium and the CIO Magazine this week announced the winners of the SOA Case Study competition. Please click here for the results.

Organizational Issues with SOA/EA ...

Last time I wrote about how shortage of critical skills in the developer community are an obstacle to full realization of SOA potentials. I got some irate responses from developers that it is the short term focus from IT management that is to blame. I must say that I did not mean to single out the developer community as the primary reason for not getting the most out of SOA, EA etc. There is plenty of blame to go around, including but not limited to over-hyping vendors, under performing technologies, cost pressures from executive suite etc. As far as management part of the equation is concerned, the biggest issue is the drive to deliver short term results. We live in a world of instant gratification at the expense of long term viability. Wall Street has proven it again and again that people are willing to throw away their long term future to realize short term gains. Bonuses are not tied to something that will pay off in long term. So, while everyone recognizes the value of architectu…

Business Architecture – Process Architecture and Information Architecture!

First the problem statement - Typically the Line of Business (LoB) owned business processes and IT owned data/ information aspects. This would then help explain why these two key aspects were never in synch. The industry is now realizing the need for alignment between the process and the informational aspects and has created a new discipline of “Business Architecture” to encompass business process and business information.

Here the idea would be to leverage the business information flow in an optimal manner to drive business process definition, business process engineering and business process optimizations as opposed to shoe-horning this crucial business information into the business process. It must be noted that business information can take forms such as rules to transform business data, business decisions made in the context of an exception in the process, regulatory influences on a process or short-circuiting rules that enable a process to either be aborted without a detrim…

Architecture tenets of High Cohesion and Loose Coupling

Architecture tenets of High Cohesion and Loose Coupling – Both of these tenets are related to one construct i.e. that of a “Contract”.

The term contract in information technology involves the definition of high level interfaces in the form of a coarse-grained set of operations that have well known inputs, output, clear exceptions or faults. The contract hides all of the details of implementation and allows these hidden implementation details to behave as one cohesive unit - in that it provides support for "high cohesion". By extension, in separating the client or consumer or caller of the contract from the implementation details it provides support for “loose coupling”.

This concept of contract works at any of the following levels:
1. sub-system interface (for example, a persistence sub-system)
2. component interface (for example, a remote monitor)
3. layers of architecture (for example, business layer vs. presentation layer)
4. infrastructure service (for example, a messaging ser…

Organizational Issues with SOA

One of the barriers to full realization of SOA potential is shortage of critical skill sets needed to successfully implement SOA initiatives. Let's be honest about the reality of the situation. Development teams typically are made up of outsourcing partners, temporary consultants, and employees. They all have varying degrees of training, skills and motivations when it comes to delivering a solution. These teams are responsible for carrying out the vision, approaches and processes laid out by the EA team. In general, the EA teams do a good job of laying out the target architecture, governance processes, best practice etc. However, the developer community is generally focused on getting things working in the shortest time possible with little regard to making sure the services have the right level of de-coupling and are designed and developed correctly for future re-use.

Having a strong governance structure can help relying too much on governance leads to a situation where the gove…

Best Practices: Master Data Management

Following are some of the best practices for adopting (note - not implementing) Master Data Management solutions within an Enterprise.

Understand the Business Context (semantics) prior to picking a solution

As per my earlier blog on EA, BPM, SOA and MDM it is very important to understand the business context, including the semantics of what each of business units, departments and entities mean when they refer to MDM entities such as Customers or Products. For example marketing deals with leads, sales with opportunities/accounts and services with paid customers. Should all the entity be referred to as customers throughout the business process? or should the master entity be referred to as Organization? Common vocabulary goes hand-in-hand with master data.For example what does this sign on a building mean? Is the building fully occupied and available for purchase? or does it mean that the entire building is unoccupied and available for rent? The business context needs to be clearly …

Enterprise Architecture, BPM, SOA and Master Data Management (MDM)

One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed and updated during the yearly budgeting cycle and my preference is to perform this activity every 18 months. The best practices (and the traditional approach) is to first document the as-is, next develop the target or future state (architecture) and finally develop a short term (6 months), mid term (12 months) and long term (18 months) road map. Preferable an actionable road map that ties back to the business initiatives.

It is good to document the the as-is (or current reality) from all the domains such as Business Context, Applications, Technology, organization and Funding. Typically the business context is best understood by identifying and mapping the key business processes at a high-level.

This approach not only helps have a common vocabulary between business and IT by identifying the key business processes, it also helps identify the key enter…

Key learning from Home Entertainment/Automation that can be applied to SOA/SaaS

Unlike the previous generation where technology innovation was driven by enterprise needs, over the past few years technology innovation such as smart phones, multimedia, game consoles, multimedia and social networking is being driven by the consumers. In short the consumers have gone digital, whether it is HDTV, Blue-ray, Home automation, smart phones, media servers or IMS (IP Multimedia Services). The vendors manufacturing these devices and services understood that unless there are standards adopted by industry - the consumers would not adopt these technologies (especially as they are not cheap). It is for this reason, most of the large vendors (hardware, software, manufacturers, protocol stack providers, etc.) got together to form the Digital Living Network Alliance (DLNA).

Their objective was to resolve the following consumer challenges:
Products designed for the home should be easy to install, provide noticeable user value and be affordableProduct must inter operate with each…

Key Best Practices - REST Assured????

The purpose of the blog is to find out if there is a place for REST in the realm of “Business Services”.

First of my definition for REST – it is a "Get", "Put", "Post", "Delete" operations performed on "Resources" that are identified as URIs being transmitted over HTTP(S) as REST.

REST by nature has a very simple service operation set with the complexity all embedded in the Resource URI. The operations that REST allows are NOT business user-friendly and hence do not really belong on the Service Repository that an end user is referencing to discover business services. To accommodate complex business behavior and to compensate for the finite list of RESTful operations the resource identifiers have to be fairly complex.

SOA on the other hand, allows fairly diverse interface definition that resembles as closely to the business syntax as it can get. The canonical model that is shared is standardized and is not as diverse as are the resource UR…

Mashup, WOA, SOA, SaaS, REST and the kitchen sink

These days there is a lot of jargon thrown around and following is my attempt to make sense of put these all together in a simple terms. A could of year back some of us, the early adopter of SOA, had put together the Enterprise SOA Maturity Model (Presentation). The maturity model for IT organizations (in simple terms) consisted of three levels starting with initially developing web applications, followed by composite (aggregated) applications and finally maturing to end-to-end (automated) business processes.

It is great to observe that some in the community are very strong advocates for Web-Oriented Architecture(WOA) as a first step towards adopting SOA. This basically validated our initial assumption that business will only fund those projects that demonstrate value and providing web based solutions is the easiest way to get their buy-in. For those not familiar with WOA - you may want to read this Blog on What is WOA - The Future of Services-Oriented Architecture . What WOA does…

3 Ps of Strategic IT

While working at The Coca-Cola Company we were introduced to the 3Ps at Orientation which were People, Products & Price which translated in something as follows:

"we need the right people to produce the right product to sell at the right price"

I would agree that this is true even today for any enterprise. In my opinion following are the 3Ps key to a Strategic IT.

As always people are the key assets to all organization, especially the ones that make a difference. This is true not only for folks in the leadership positions but also the developers, system administrators, administrative assistants as well as the security guard at the data center. It is important to identify the exception and key people within an enterprise and do whatever it takes (within reasons) to keep them.

Even though business keeps asking for solutions, which could be a packaged or custom applications - the platform on which it developed is key. In my experience, even if we adopt a pac…

Business Agility and Business Driven EA Domain Models

For my presentation on the topic of SOA and Business Agilityat the IC - local chapter event last month I had refined slightly the Business Agility Domain Model. The pdf version of slides on the domain model are available here and is based on my original blog on Defining and Measuring Business Agility. I have been planning for a long time to develop a spread sheet that goes along with - maybe someday I shall get to it.

Over the last few months I have helping my customers understand the role and importance of Enterprise Architecture and came up with this EA domain model (also referred to as the "circle of happiness" by one of my potential customer :) ).

The Business Driven Enterprise Architecture consists of the following domains:
Business Architecture (or Business Design)Competency Center -Check out this SOA Podcast on SOA COE by Melvin Geer published by the SOA Consortium.Enterprise Architecture - check out all my blogs on this topicGovernance - Corporate, IT, Enterprise Arc…

SaaS requirements for Large Enterprises

Thanks to Annie once again for forwarding me the article on SaaS Star leaves SAP Executives moving to competitors is nothing new it was not long back that most CEO's of large software companies in the Silicon Valley were Oracle Alumni. As Larry could not retain them - he went and bought them :). Sorry - I digress.

While reading the article - the following quote caught my eye.

“SAP doesn’t have a SaaS strategy,” he (Steve Lucas) told me. “They don’t have a single piece of paper that states what their SaaS strategy is.”

I don't know Steve but if he has already made this statement to the executives of SAP while he was there - they kudos to him, otherwise this is PR at work (and very good at that).

Don't get me wrong - I like, they are a great company and the market leader in the SaaS environment. A couple of months back I did develop a "Application Portfolio and Time Reporting" prototype - it took me a couple of days to…

Best Practice: 5 things that the CIO should focus on

Following are the 5 things that the CIO should focus on in the current environment.

1. Focus on the Demand Side of business
As per my earlier Video Blog on the Changing Role of C-level executives - CIO need to focus on the two sides of the business - the demand and the supply side of busienss. Today most of the CIOs are focusing on the supply side, i.e. helping reduce cost, timely delivery of projects, outsourcing and off-shoring and so on. Yes! COIs do also focus on the Demand side - but not necessarily the primary focus for majority of the CIOs.

The demand side basically means focus on the business demands for new or modified solutions and widely known as Business Agility (read my take on Defining and Measuring Business Agility). CIOs would do well to establish the Business Architecture discipline within the Enterprise Architecture team to help understand and prioritize the demand side of the business.

2. Establish a strong centralized function
Agreed that the LOB-IT is essential to pr…

Analysis on Oracle's BEA integration strategy

Oracle presented it's BEA product integration strategy earlier this morning and following is my take on their approach. Their market message about Fusion, Applications and Database did not change - this was more about integrating the product stacks. On the whole this is good news for existing Oracle customers who have standardized on Applications and Fusion but not necessarily for the one's who standardized on BEA's stack (especially Portal and AquaLogic).

Following is how Oracle categorized the combined product stacks:

Strategic Products: IMO these are the primary products where they shall continue investing and great news for those who have standardized on these productsContinue and Converge Products: IMO - they will increase the support price and shall keep it going for the next 9 years. Customers who have standardized on these products WILL have to migrate to a different product within 9 years.Maintenance Products - EOL productsOracle classified their products into…

SOA and Outsourcing

Despite many of its shortcomings, outsourcing is here to stay. Businesses are addicted to outsourcing and outsourcing is viewed as low risk (we have someone to pass the buck or blame if things don’t go right). IT departments have come to view outsourcing as a normal mechanism by which costs can be lowered. While this is true most of the time, sometimes uncontrolled outsourcing can limit IT’s ability to take advantage of emerging trends such as SOA. Let’s see how things can get ugly fast. In a typical data center outsourcing scenario, the outsourcer will probably assign a pool of resources to manage the infrastructure with the assumption that individual familiarity with the environment is irrelevant as long you have robust process (read: bureaucracy) in place. It works in theory but the reality is that in a shared services environment, you simply can not assign just any systems administrator to troubleshoot problems. The familiarity with the environment is essential or else you risk im…

IT Engagement Model

One of the key ingredient for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT with each doing their best to provide the highest level of support to the business. Most of the time this results in people stepping over each other - especially as there generally is a not a clear definition of everyone's task. Most of the project failures are due to the confusion is the definition of the roles between the PMO, Project Manager and the Enterprise Architects, resulting in responsibilities overlap and lack of making decisions.

It is important to do this in the context of the Services Life Cycle and did publish a short presentation on this topic a couple of months back. This presentations is a summary of the SOA Practitioners Guide Part 3: Introduction to Services Life Cycle with the addition of the IT Engagement Model slide (14) shown below.

This is the RACI (Responsible, Accountable, Consulted and Informed) slide listing all the r…