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 lot of resources (and $$$) without any major differentiation. It may be easier to subscribe for the same applications from a SaaS provider.
• Do invest in a few strategic initiatives
• Do not attempt to crawl before you run - "run baby run". The company that runs the fastest to meet the customers demand WILL WIN.

Just some of my final thoughts to close out 2008 and as usual please do feel free to drop me line with your comments and/or feedback.

Wishing everyone a very happy and prosperous new year.

Yogish

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 technology
• These 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 longer you wait the worse it gets.

Hmm!! - haven't I heard this before? :)

Yogish

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 Architect
• All EA members reports to the head of the EA team
• Individual EA are either focused on some core technology, IT functions (such as networks and operations) and Business Domain
• Business 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 team

As 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 Architect for the company who reports to the CTO of the organization
• Evey business unit has a Chief Architect who directly reports to the Head of Engineering of the business unit and dotted line to the Chief Architect or the company.
  
• The Chief Architect sometime reports directly to the GM of the Business Unit.
  
• The GM of the Business Unit and the CTO typically report to the CEO
• The head of engineering reports to the GM or is also the head of the Business Unit (varies - no consistent pattern observed)
• The success or failure of this pattern is directly dependent on the leadership skills of the Chief Architect of the Company
• The Chief Architects of the Business Units also play an important role and will be effective only if they constantly communicate to each other
  

As the GM like to have a sense of ownership - this organization pattern makes sense of the High-Tech industry. If the Architecture team is centralized under one Chief Architect - my observation has been that the GM then hire their own Chief Architect (under some other title) which creates a huge organization conflicts.

Some Interesting Observation:

• One of the companies during the transformational phases transferred all their key resources - including development managers, developers, DBAs, Operations, etc. to the architecture team. Made a public statement that Architecture team was core - reorganized the rest of the teams and later over the three year period transferred the folks back out to the new organization. Using the Architecture team to retain the best resources during their transformation phase.
  
• There is a 50% split between Shared resources team as being part of the Architecture team or an independent team.
  
• Lately over the last 12 months - a lot more companies in the Silicon Valley are looking or Chief Architects responsible for both Business and Technology Architecture. However, they do not explicitly mention Business Architecture in their job description but their job description includes Business Architecture responsibilities.

Just some of my observation about the Architecture Organization Patterns and as usual please do feel free to drop me line with your comments and/or feedback.

Yogish

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 responsible for these quantifiable returns delivered by following SOA principles. Advertising the benefits of SOA style services with the benefits rendered by these projects help the business to relate to the abstract constructs such as SOA and so offer a better chance for service adoption. Also, advertising these business services that deliver efficiencies can be shown to offer speed to market gains that can be used for upcoming projects by encouraging reuse.

E) As always one should not assume technology will be the magic bullet. An assessment has to be made to understand if all components of the process/ business capability have to be refactored into services. One has to be open to leveraging legacy assets to reduce risk even if all that can be achieved is establishing a document based interaction or a mediated invocation of the legacy system.

Your feedback is invaluable.
Thank you!!
Surekha -

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 mortgages
• Investment bankers and mortgage companies composed new and complex derivatives and resold them all across the globe - all in the name of new and investment models
• Most 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 late
• The 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 the result today. Doesn't this sound familiar?

Following are my recommendation on how to make sure that our SOA adoption does not take the same path (some will).

• Make sure that all SOA adoption is based on sound business and technical foundation. Adopt and make sure to document the business architecture (design) and develop a technology road map (architecture) to meet these goals.
• Do not hype and push rapid adoption without thinking through the life cycle .
• Ensure that there is proper governance around your SOA Adoption - over communicate and be a bit more conservative on the risks.
• It is not necessary to adopt SOA for all implementations - I would rather then to recommend that one makes sure that some of critical business capabilities (applications) are provided (build) using the traditional model.
• Do not depend on services that are more than two level deeper (Reference: SOA Theorem #4: Service Hierarchy should not exceed more than three levels ). This is to ensure that you understand each of the services and their performance which will help you take corrective action, if required.

These are just some of my initial thoughts and as usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

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 model could be used to define a request model that is a representation of the service provider search/ browsing parameters and service consumer's usage context. Here the search capabilities of a search service could use search/ browse related grammer rules to interpret the search context that is embedded into the request by the consumer. The context provided by the consumer allows the service provider to "accurately" and "efficiently" interpret the request.

For example, search semantics embedded in a search service that returns cross-sell product options could include information like "customer preferences", "type of credit card used by customer", "shipment processing preferences", "customer purchase history" etc। This type of "customer information" represents usage semantics embedded in the request and allows the provider to return cross-sell product options that are geared to the the specific customer being refered to by the consumer call। This in turn allows compilation of product suggestions which incorporate the profitability levels and purchase ability of this particular customer. The "customer information" is deemed to be the search result and usage context that are sent into the search request. These search results are thus customized to the consumer context without the consumer needing to make multiple calls to get the desired results. Therefore, one could see how the canonical request model has not only the standard search parameters supported by the provider but also allows the consumer to express its' search context and how it might apply the results of the search/browse call.

In addition, the canonical request model based search context could be used by the consumer to drive processing efficiencies in the provider। These request based keywords/ context can help the provider eliminate or short-circuit certain types of processing as well. For example, a canonical request model could support "new customer search" vs "existing customer inquiry" keywords to help alter the providers' audit processing behavior and past inquiry Here a consumer call with "new customer search" context could be used to suggest to the provider that the audit/ security and past inquiry lookup be disabled thus positively impacting the response time of search call.

In conclusion, we can see that the consumer usage semantics allow the provider to tailor it's search behavior to the needs of the consumer without changing the provider service interface.

Please give me your feedback on this topic। Also, I would be interested in knowing whether or not you have leveraged these concepts in your industry vertical।

Surekha -
Thank you!!

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