Launching MDM as Part of Larger Initiatives

Let me walk through a situation that may be common in many organizations. You as an IT visionary recognize the need for MDM initiative but are having difficulty appropriating funding due to cost concerns or simply as a result of organizational inertia. You decide to ride the coat tail of another major initiative that is somewhat related to the successful implementation of the MDM. Is it a good idea? I would suggest yes, but be careful about setting expectations and having the right level of buy in or your successful execution of MDM initiative may be perceived as not so successful. This may happen due to personalities involved or not having MDM implementation risks included in your schedule or cost estimates. You can be sure that you are going to run into data issues, and amount of data you wil have to deal with will always be more than you think. All these issues may impact the larger intiative and will reflect badly on the MDM effort.

Make sure all stakeholders understand that while MDM is expected to support the larger initiative, it has its own benefits and its goals are much larger in scope. Also, include additional time and cost to mitigate the risks.


Ashok

Economy and IT

All the bad news about economic downturn got me thinking that there are a few parallels to be drawn between the cause and effect of current economic situation and IT. Just like American consumer, we have to start thinking about making some adjustments that will be required in future. Lets look at some of the parallels first:

Exotic instruments – One of the reasons financial system came crashing down was the invention of exotic financial instruments such as Collateralized Debt Obligation (CDO), Credit Default Swap (CDS) etc. These instruments were not well understood by majority of people that were peddling it or those that bought into it. We in IT world have been living in alphabet soup of our own – EAI, AI, SOA, BPM, CEP etc. While some of these acronyms have legitimate meaning, most are there to sell products or consulting services. In financial world these instruments have led to illusion of profit thus fat bonuses for undeserving people. In IT world this has also led to fat profits or career advancement for undeserving people

Sub-Prime Mortgages – IT equivalent of sub prime mortgages is the foolish investments we have made over time in technologies that have failed to pay back (they are the financial world's equivalent of "Upside Down" mortgages). Now, any new technology investment is risky and we should not be totally risk averse otherwise we will miss the opportunity to take advantage of transformative technologies such as the Internet, but at the same time we in IT tend to over hype any thing new. "If only I go ahead and buy a new CRM package, I will have better customer relationship." I am sure every organization has a number of expensive software products that have either been abandoned or are under utilized.

Next time I will talk about the adjustments. Anyone here with me for a “BAILOUT”?

Ashok Kumar

Architetcure in 2009

This will be my first entry into the blog for 2009. It has been a while due to a lot of churn over last few months. I am happy to see 2008 go. The only fear I have is that at the end of 2009, I don’t want to be longing for 2008. What a brutal year. I am hoping that people have learnt some lessons that you can not always focus on short term results at the expense of doing the right thing that has long term value. Architecture falls in that long term value category, yet first thing organizations do when it comes to cutting costs - they sacrifice architecture. Why do we keep rewarding people that cause untold harm in the long run while seemingly achieving short term goals? Most IT organizations fall into the same category. Senior executives are rewarded based on short term gains or operational efficiencies at the expense of long term viability. Current environment will only exasperate the situation.

It seems to me that executives and boards have not met the responsibilities entrusted upon them. Most executives have only been interested in benefiting themselves. I believe that executive bonuses should be kept in escrow and only be handed out at least 3-5 years after they are eligible to receive it. The disbursement of bonuses should be contingent on meeting some tough criteria where it is clear that no long term harm was brought upon by actions of these executives that may have fattened the bottom line in one year but killed the company over long haul.

My apologies for ranting but it has been very frustrating last few months. Now we need to focus on future and adjust accordingly. One trend I am seeing is that without clear, measurable ROI, funding is going to be scarce. There are fewer (if any) opportunities to experiment. This also means that vendors will have to adjust their expectations and will have to prove beyond power point slides that their product is worth investing in.

Happy new year everyone.

Ashok Kumar

Business Architecture

I have been having intense discussions lately on the topic of Business Architecture. I have looked at TOGAF, Zachman and other sources to find out what the experts are saying. I have also been talking abbout this with my colleagues at SOA Consortium to see what they have been doing in this area. It appears that while we all understand IT Architecture fairly well, there is less clarity when it comes to Business Architecture. Is it Process Modeling, Value Chain Analysis or something else that constitutes Business Architecture?


We can all agree that the purpose of any Architecture is to manage change. In order to manage business change effectively, we need to understand how a business is designed. It is this understanding of the design of business that is essential in managing business change. Additionalyy, there must be active management of a business design otherwise business design has very little vaklue. The bottom line is that some form of business architecture exists in every business simply due to the fact that a business is operating, producing goods or services and serving its stakeholders. What is generally missing is the formal representation and management of the business design.


I would propose that Business Architecture therefore is both formal representation of a business' design and associated processes and organizational structure to manage the on going evolution of the business' design. The question is what is the right way to represent a business design. A number of approaches are available including Process Modeling, Business Motivation Modeling, Value Chain Analysis, Six Sigma, Lean etc. Similarily what are the right processes and organizational elements that can yield an effective business architecture. I dont thins there is a single answer to this questions. We will explore this further in future postings.

Ashok Kumar

Key Best Practice: Separation of concerns - the age old best practice!!!

Here I thought that reiterating the principles of separation of concerns would provide a great rrefresher.


It is my contention that architecturally it is a good idea to keep the persistence layer and the business logic layer separated just as it is to keep the presenation layer and the business logic layer separated. Especially, in the age of SOA this make a great deal of sense as it enables each layer to change independantly to enhance the overall agility and robustness of the solution and to increase the responsiveness to the business needs. Here I expound on the reasons for the separation of the persistence layer from that of the business logic layer.

A) Keeping the business logic from being comingled in the same objects that hold persistable fields (that are tied to the persistence store layout or database schema) is important as this separation of the persistence fields from the business logic allows the application/ component to deal with the changes to the database schema more efficiently. The corrolary is also true in that persistence related objects/entities are insulated from the changes to the business logic.

B) The separation of the business behavior from the persistence layer may have an added advantage of allowing the implementation and testing of the business behavior to remain independant of the implementation and testing of the persistence behavior.

C) In addition, these persistence related domain entities could become simple state encapsulation entities (DTOs) and could become the sole constructs that are traded/ exchanged between the persistence layer and the business logic layer

D) These state encapsulation entities (DTOs) could also be shared as parameters between components and/or applications and could be transformed into XML long as they all belong to the same business domain.


Your feedback is appreciated.

surekha -

SOA:Many Things!

SOA: Many things

SOA is not one but many things! Recall the story of blind men and the elephant; each one comes up with a different interpretation. Our individual perceptions and role in an organization is not an adequate basis to describe the entire SOA beast. Agendas of individuals or organizations defining SOA make it even harder to fathom through the myriad. For instance, for a vendor with a product line of applications, SOA is just web services. For a technologist, it is an IT issue and all about SOAP. SOA is about legal contracts for the general counsel, or delivering a business capability for a CIO.

In short, SOA means many things to many people. Yet we are not blind and should not be constrained by a narrow view. Thus the overall definition of SOA must arise from collective nature of the enterprise, with input from its constituents.

Let’s consider a situation involving the return of unused goods. In this typical reverse logistics scenario, understanding of a service varies from technologists to non-technologists, each with different priorities. For a technologist, a service is a network-enabled software component, which provides a specific capability. For a non-technologist, a service is some form of offering supplied by an organization that receives merchandise return requests, sends directions for shipment, updates inventory and applies credit to the customer. A customer service representative will make sure that customer requests are understood and s/he gets the information for the return. Shipment and receiving will be your focus if your role is operations. Accounting will be more interested in applying appropriate credit to the customer. While each participant has a defined focus, overall goal is to establish a means of delivering value to the customer.

This complex situation involves Customer Relation Management, Supply-Chain Management, and Enterprise Resource Planning. SOA solves this complexity by

• Decomposition
• Aggregation
• Orchestration

SOA decomposes this business process into well defined discrete services: some are automatic, some are manual, some short-lived and near real-time, some are long-running requiring human-intervention. Services may be aggregated and then orchestrated to create additional services depending on the granularity level of decomposition.

After all, a service is a unit of work done by one entity in order to meet the need of another entity. The primary entities in SOA are the service provider and the service consumer. At any point, the roles may be reversed, consumers becoming providers and vice versa. The consumer enjoys the value created by service without the ownership of the specific costs and benefits.

Service interactions, however, must be defined unambiguously for both entities to successfully communicate. Each interaction between the participants must be self-contained in a service contract, focusing on a specific capability. A greater synergy is achieved by the orchestration of these services in a coherent manner.

SOA embraces the fact that each entity may have a drastically different environment. Distinct systems or applications deployed at various agencies can interoperate because SOA makes as its pinnacle the use of ubiquitous XML which poses no limitation by platform or language. Choosing JAVA, .NET, or a mixture is not a headache anymore! By placing emphasis on business activity rather than implementation details, SOA can make that crucial inventory drop arrive at a warehouse manager’s Blackberry™ to shore up just-in-time measures. By adhering to the service contract, an organization can easily swap out its implementations or move to other locations. A service for sending out information to customers, for instance, may be reused by multiple departments.

SOA is more than a buzzword. It is the way for organizations to rapidly develop capabilities, to collaborate and meet the expectations of their stakeholders. SOA’s agility makes it an enterprise business strategy, however.

SOA may also be DOA, dead on arrival, if we narrowly assume that it is just a bunch of web services, a product or a panacea for integration nightmares.

Some organizations get their feet wet with a few services by creating prototypes and exploratory projects. This is a good point of entry for the technologists but the business executives need to start thinking big at the onset. For businesses, a concerted effort needs to be made to launch a SOA lifecycle at the enterprise or the segment level. A typical SOA lifecycle includes three stages:

• Initiation
• Roadmap development
• Plan execution

For continued success, the lessons learned in execution should create a feedback loop to the roadmap.

SOA initiation needs both business and IT to cooperatively decide on the business process that will be built or replaced. Creating the team and setting a project plan is necessary. Roadmap development establishes the SOA principles and reference architecture for business and technology (application, data, and infrastructure). Governance will guide with policies, measure effectiveness, control for compliance, communicate to inform all parties, and above all, empower for better decision making. Program management assures that the project is on time, on budget and on scope.

The SOA lifecycle is about implementing SOA enterprise-wide. It gauges smaller pilot projects to be on par to address the need of the organization and paves the way for properly scaling up. Once business and IT decide on the services, avoiding DOA requires establishing a Service Lifecycle to manage individual services.

Service lifecycle spans the activities from inception to retirement or decommissioning of a service. There are three stages:

• Requirements and Analysis
• Design and Development
• IT Operations

Following a service lifecycle assures accurate capture of business requirements, development of IT solutions that match business requirements and deployment/maintenance of services that provide business capabilities encapsulated in the requirements.

Starting a SOA lifecycle, or for that matter, choosing the candidate business processes along with governance, is not a small feat. A misfiring engine can cause headaches in the long drive. Choosing a vendor in this endeavor may be the biggest investment an organization may have to make in climbing the mount SOA.

Note that SOA is neither a product nor a single solution, but rather a comprehensive business enablement with IT elements. Make sure that your vendor is capable of bringing together business and IT stakeholders in a face-to-face collaborative where you, as an organization, not the vendor, make the decisions. After all, who knows your organization better than you? How rapidly will your vendor comprehend and assess your business processes to enable you to sail into service decomposition? Think big and ask about the end game. Establish governance and a program management. Spot the need to change early, especially organizational changes. Start small with services representative of your environment then you are ready to scale fast!

Burc Oral

http://www.linkedin.com/in/burcoral
http://www.soa-consortium.org/

Selling SOA to business

One of the most important milestone in SOA adoption is getting the business to buy in. However, getting business buy in requires an approach that is sometimes not obvious. I had an interesting conversation with Jon Brodkin of Network World. Please check it out at



http://www.networkworld.com/supp/2007/ndc6/102207-avis-soa-case-study.html



and let me know what you think





Ashok Kumar

Integration Tomorrow, Part 2: SOA Architecture

Part 1 of the two-part series described the past and current integration approaches. This second part, takes a practical approach on how technology is going to change business landscape and the potential infrastructure changes required to integrate the business both at business and IT levels.



Read more about this here.

Integration: Then and Now, Part 1 - SOA Architecture

Integration of business systems is one of the key capabilities that should be provided by IT to enable business agility. This has been the primary objective of all integration effort to date; however, due to various factors most of the integration efforts have not achieved the expected business benefit. Of course, projects with the right executive backing have been successful but have never reached their full potential. The objective of this column is to demonstrate how adopting a service-oriented architecture (SOA) enables a company to achieve business agility and flexibility. This is a two-part column; this first installment deals with high-level integration architecture based on SOA and the second will focus on SOA governance.

Read more about the first column here.