The P&C business glossary and data model(s) were created to provide a common framework and language within an organization and the industry, improving communications and expediting development turnaround and quality.

The deliverables of the initiative include:

Beyond the individual expertise involved significant intellectual property donations were made by participating organizations such as process models, data models, business glossaries, and tools.  An example is the Business Glossary from the IAA which was donated by IBM.

During our last consortium meeting on 3/19 there was great dialog on the usefulness of the end deliverables… the “value proposition” in a sense.  A partial list of the ideas shared included:

• Facilitate mergers, acquisitions, divestures and/or enterprise transformations
• Facilitate B2B data interchange/ecommerce/exchanges/portals
• Helps to drive SOA adoption/BOR development/application interfaces
• Supports CRM initiative which may cross business units/products
• Supports information management/reporting
• Facilitates package development/adoption/integration/migration
• Facilitates business requirements attainment; provides glossary as a starting point
• Provides starting point for metadata repository
• Jump starts/supports business architecture/capability models
• Supports regulatory/compliance activities and concerns
• Supports data quality initiatives

Notice the consistent use of the words like supports, facilitates, and provides?  For me, the most important use of the model is as a communication tool.  One of the most difficult parts of any requirements gathering, report defining, or process modeling activity is understanding the underlying data requirements needed to satisfy the project.  It is difficult enough to “speak the same language” across functional areas within a company.  We are using draft versions of these deliverables today to greatly reduce the time and improve the quality of our requirements gathering activities.  In some ways this is the simplest use of the model, but also perhaps the most valuable.  Many of the other ideas that were presented above are actual in-flight use of the model by other participants.

To date we have over 50 organizations that have participated in this initiative, spanning carriers, vendors, and consulting organizations.  We want this model to represent as broad a range of experiences and viewpoints as possible, so if you are interesting in participating check out the Wiki for this initiative: http://www.omgwiki.org/pcwg/doku.php.  Anyone interested in providing support to the initiative should contact me for further infomation.

Traditional market research is conducted via a number of  mechanisms ranging from pretty slow to uselessly slow.  Focus groups, polls, mass media responses, etc. all present timing and filtering challenges to organizations that want to know what their customers are thinking and feeling now, and how they are altering what others feel minutes from now.  Enter a new breed of “Listening” technologies that allow for more rapid analysis of customer feedback.  One such technology is provided by ListenLogic and represents a class of products that allow for sophisticated analysis of the conversations being held about your products and services, in near real time.  The ListenLogic service is able to intelligently comb through practically all internet traffic to find different pieces of information relevant to your organization.  Blog posts, wiki entries, comments on news articles, twitter posts, and many more social media sources are reviewed, analyzed, and complied into exceptionally (almost magically) relevant feedback about your products and services, and all with only a slight delay (typically in the 20 minute range) from original posting.  Imagine being able to launch a new product and start to receive feedback from an exceptionally diverse customer set mere minutes later.  The power to listen has become so strong, there is really no excuse for a lack of understanding about customer concerns.

But with great listening power comes great communicating responsibility.  It is not enough to be listening to your customers, one must also have a strategy to respond in a thoughtful, frank, and rapid manner within the social media channels in which the conversations are occurring.  Without a strategy in place to listen, assimilate, and respond, along with a staff savvy in the social media tools of the day, your organization will be limited to traditional media channels for responses.  This does not allow for continuation of the “conversation” that occurs via these social media channels and alienates your organization within this community.  A press release is not enough in this setting (in fact, the press release is a dying medium in its traditional form as evidenced by the struggles of the folks that publish said releases), organizations must open a dialog with customers on their own turf, namely the social media sites themselves.

Do you follow the tweets of influential folks on twitter?  Are you reading key blogs to get a pulse on topics relevant to your brand?  Are you scouring product review websites to see what folks are saying about your wares?  Do you have time to do any of this by hand?  If the answers are no, you need to develop a strategy to listen, employ the best tool set possible to assimilate the data for you, and respond via a host of channels that help continue the conversation.

Engage in these new and influential social media forums, your reputation will thank you.

In SOA Governance, Who Has the Authority?

In my opinion, the short answer is the CIO is accountable for (service-oriented) architecture.  

The long answer involves first addressing 2 key buzzwords associated with the question:  SOA and governance.  I leverage MIT’s IT Governance model when defining SOA governance:  SOA governance involves specifying decision rights and accountabilities for important SOA-related decisions (e.g., service design, service version control, service deployment, etc…).  In practice, I actively promote using a responsibility assignment matrix (RAM) to aid in implementing SOA governance as it clearly identifies: (1) what decisions need to be made, (2) who is involved in the decision making process and (3) each individual’s role (i.e., responsible, accountable, consulted, informed) with respect to the decision.  In my opinion, SOA is a contemporary approach to enterprise architecture – i.e., the overall design of an organization’s many and disparate information technology assets and how they link together to enable the enterprise’s business processes.  SOA promotes deconstructing business processes into discrete, reusable and standardized services.  It’s an architectural style that can lead to enterprise agility, flexibility and lower costs.  

Second, we need to understand the tradeoffs associated with ‘centralization’ versus ‘decentralization’ issue.  The former often leads to economies of scale; the latter permits local innovation.  The “optimal” configuration depends on the business model.  The business sets the direction on which business processes and data should be centralized or decentralized.  IT organizations should align with this direction.  The advantage of SOA is that it’s a flexible architectural pattern that facilities this alignment.  

Feedback including my own:

http://www.ebizq.net/blogs/ebizq_forum/2009/10/in-soa-governance-who-has-the-authority.php

Towards the end of the nineteenth century, a mere 50 years since first automating the manufacturing platform, several engineering breakthroughs led to the possibility of generating and distributing power through an alternative delivery model:  large-scale electric utilities.  These utilities’ superior economics of scale would enable them to deliver power at a much lower price  point than manufacturers could attain with their own power-generation equipment.  Manufacturers could now simply focus on their primary business – manufacturing. Makes more sense, eh?

This is strikingly similar to where we are now in the information age.  Since the mid-twentieth century, modern businesses have invested trillions of dollars in not only enterprise software, hardware and systems integration services but also the data centers and technicians required to host, install and maintain their complex data processing operations.  Much like their industrial age counterparts, no matter what their main trade might be, each modern enterprise has had to also be in the business of information processing.   

That is until now.  A mere 50 years since the dawn of the commercial computing age, engineering breakthroughs (e.g., hardware virtualization, ubiquitous high-speed bandwidth) have led to the dawn of an alternative delivery model in data storage, processing and manipulation:  cloud computing.   Now, in lieu of operating their own private computing systems, modern firms can tap into centralized computing plants capable of data storage, data processing and data transmission.  And much like their historical brethren, these cloud service providers (CSPs) face the same challenge that electric utility providers faced a century ago – “convincing industrial businesses that they should stop producing their own power and instead buy it as a service from central plants.”  Some major enterprises like Home Depot have been convinced and are reaping the economic rewards of this new paradigm; others like Pulte Homes convinced but perhaps misled.  As the relevant technologies and cloud architectures mature, the superior economic benefits associated with centralized computing supply will eventually be too great to resist and every enterprise will leverage the cloud computing platform.

* RB *

For example, take Pulte Homes’ foray into the cloud as described in CIO Insights’ Know It All September 26, 2009 column.  Cloud computing [aka utility computing, on-demand computing, grid computing] is a contemporary computing style in which dynamically scalable and often virtualized resources are housed outside of one’s own data center and “automagically” provided as an on-demand service over the Internet. Better yet, most commonly pay for the services “by the drink” thus eliminating the need for large upfront data center investments and continuing support fees.  [Yes, after several years and millions spent virtualizing their existing data center assets (e.g., servers, storage, etc…), the technology delivery paradigm has shifted once again on our CIO brethren.]  For example, need server hardware, operating systems software and storage immediately?  Call Amazon’s EC2 for Infrastructure-as-a-service [IAAS] to provision your variable needs.  Does your business require a customer relationship management system tomorrow?  Phone salesforce.com for their CRM Software-as-a-service [SAAS] and you’ll be up and running as soon as your credit card is authorized.  Sounds remarkable easy, eh?

Well, like an emerging business technology trend, it’s critical to define an adoption roadmap for the unique goals and strategy of your organization.  Recall earlier this century when traditional outsourcing arrangements [e.g., the US Navy/EDS debacle] were fraught with scope, contracting and knowledge transfer risks that often manifested as issues.  Much the same can be said for cloud migration.  Without a detailed architecture and transformation roadmap the risk of “taking an arrow” unfortunately increases significantly - pioneer or established settler.  And, as in the rest of life’s travails, a little luck doesn’t hurt either. 

What is REST or SOAP?

REST stands of REpresentational State Transfer for those who are curious.  Simply put it deals with expression of enterprise data in its enterprise form. Where as SOAP which stands for Simple Object Access Protocol, focuses on how enterprise data is processed; what operations are performed on enterprise data.

The Debate

Both REST and SOAP services inherently are designed solve a slightly different problem. While the analogy is not of apples & oranges, its more like Washington Apples vs Granny smith apples.  The problem (also the confusion) is that if one is determined or biased enough towards either, he/she can almost always make the shoe fit.  Therein lays the problem.  Purists, and Technologists are quick to cast their vote in favor of one technology or other based on some obvious differentiators such as performance, security, interoperability, portability. Etc.

It is important to note that the decision to adapt SOAP vs. REST is not mutually exclusive.  Both can co-exist.  Both can be built based on same technology stack (generally speaking).  Both share basic paradigm of using XML to exchange information.

Strengths of REST services:

1. REST services result in stronger data centric view of enterprise information products.  With SOAP based approach, one must make a concerted effort to maintain enterprise Document Model consistency.  REST services solve this problem in the way they are realized.  That is, the approach to doing the analysis for REST services involves under taking the analysis of enterprise information products, data classification, and data dependency analysis to name the few.  This is different from typical top-down SOAP based service realization process which involves more of business requirements analysis.
2. REST services really shine for “read-only” data access. Ideal systems are those which involve “inventory lookup”, “Parts search”, etc.
3. Typical consumers/uses are Web-based UIs, backend data-centric systems

Strengths of SOAP Services:

1.  SOAP services result in API centric view of enterprise information systems.
2. SOAP services are better suited for charge back model
3. SOAP services are realized based on business analysis (as mentioned earlier) in a top-down approach or based on existing systems (bottom-up).
4. SOAP services are generally integration focused and are used for system-to-system integration.
5. They tend to be a bit more complex to develop, & design since they offer standards based Security, Transaction, Attachments, and an array of communication models (Synchronous, Asynchronous, Request/Call-back, notification etc.)

Performance, however, can not be considered as neither strength nor weakness of either of the two for one simple reason: performance is a measurement of a system in a given business (or consumption) context.  Without the context, you are always comparing apples & oranges.

Lastly, the jury is still out on the “cost of ownership” issue between REST and SOAP services despite what the purists will have you believe.

So which is best suited for Enterprise Integration: SOAP or REST?

The answer to this question is surprisingly simple, partly because this is a trick question. 

As an Enterprise Architect responsible for setting architectural standards and guidelines, and as a leader in the enterprise architecture governing body, one must not look to banish certain types of architectures in favor of others.  The key is to define the guiding principals which describe the kinds of situations where one particular type of architecture should be adapted rather than the other.  Then leave the decision of adopting a particular type of architecture to the solution architects since they are likely to understand the project needs better than an enterprise architect serving remotely on a governing body. 

Allowing project architects the discretion to choose a particular architecture based on defined architecture guidelines and project requirements, opens a new challenge for the enterprise architecture governing body.  The body should now mandate Architectural Audits at key junctions of the project SDLC.   This is fundamental part of SOA Governance and long term success of SOA implementation in an enterprise.

If you go to a surgeon with a bad knee, most likely he will want to operate. If you put architects and application owners in charge of application rationalization/optimization, they will want to “architect”. It is difficult for technologist accustomed to designing and developing applications to resist the urge to build the ultimate technical platform rather than focusing on what needs to be done, why, and in what order. Furthermore, it is important to keep Andy Kyte’s (Gartner Fellow) 1^st principle of application rationalization in mind: “Today your organization has exactly the right number of application to run the business the way it runs today.” Taking this to the next logical step, one can see that any application rationalization will have immediate business impacts. Therefore, it is futile for IT to act alone in application rationalization. If you want to spend a lot of time making pretty quadrants, ranking applications, determining future fit to the organization with zero tangible outcomes, by all means run your application rationalization without business involvement.

Since you would rather not waste your time polishing your PPT skills, get business involvement early and identify key individuals that will actually commit to your application rationalization (not just “steering” committee roles but actual hands-on work). Focus your efforts and data gathering on three areas:

1. Financial Data – get as much detailed cost information you can about the applications in your portfolio. Ideally you want to get TCO for every application. Short of TCO data, you need data that can be “defended” if challenged. Plot your cost data over a defined time horizon to show a trend. Most importantly, the future cost graph will help you determine the cost of inactivity (i.e., if we did nothing with X application, it would cost us Y).

2. Application Utilization Data – identify meaningful metrics for each of your applications that can easily be extracted (e.g., for a purchasing application, measure purchase orders). Then, plot these metrics over time to reveal applications with increasing/decreasing usage.

3. Risk Data – analyze the risk of an application using a bottom-up approach. Begin with the technical stack (hardware, operating system, database, etc.). Asses the likelihood of a failure and the impact of a failure. Also consider your staff’s skill-sets and their ability to rapidly address an application outage.

Once you have gathered the data (probably 2/3 of the effort in an application rationalization effort), you are ready to perform the analysis and make prioritization recommendations. It is helpful to classify applications based on disposition statuses such as maintain, reengineer, replace, or retire. A key point here is to define disposition statuses that make sense for your organization (don’t use technical jargon – use plain English!). For example, an application that should be “maintained” will most likely still require technical upgrades and service pack application. However, in some organizations that may be considered “running the business” while others may call that “reengineer” since a maintain application should be completely left alone.

At the end of all this, your goal is to have a prioritized set of application related activities that will lower costs, reduce complexities in your application portfolio, increase customer satisfaction, and align with the direction of your business strategy. If done in lock-step with your business counterparts, none of this should come as a surprise and the business will be willing to make the necessary operational/procedural changes to support the application rationalization recommendations.

Let me know your thoughts and experiences with application rationalization. There is clearly a mix of “art and science” and I’m always interested in hearing what the “artistes” out there are working on!

Collaboration can be framed in terms of how it impacts People, Business Processes and Organizational Knowledge. Processes address the methods, applications and rules which define and govern how work gets done. For example, order fulfillment, new account development, employee on boarding, web site publishing, product development, etc. Knowledge and knowledge management refers to the development and utilization of a company’s information assets. Corporate knowledge has many forms. Orders, claims, trades, accounts, contact info, project data, relationships, etc. The people component of collaboration encompasses employees, roles and responsibilities, skills and knowledge. It refers to the organization as a whole and can also be framed to include customers, business partners and suppliers.

All of these areas are encompassed by Microsoft’s SharePoint Services: Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS). The services related to SharePoint (Migration, Customization, Assessment, Proof of Concepts) have always been a strategic area of investment and services for LiquidHub. It is from this investment that we have created our Collaboration Center of Excellence.

The Collaboration Center of Excellence is focused on helping companies utilize the full capabilities of SharePoint (Windows SharePoint Services / Microsoft Office SharePoint Server) in the areas of administration, configuration, development, training, and support. Our approach helps our clients

• Integrate SharePoint with current processes
• Integrate SharePoint with existing Enterprise and Legacy systems
• Jumpstart application development using SharePoint

It is from this we decided to publish a digest of articles to you, to better help you in your appraisal of SharePoint, and to provide you with knowledge on how you can maximize your business process through the utilization of Microsoft’s SharePoint Services. Our digest will be published periodically with Productivity Tips, Best Practices, and Real-World Practices to assist you with your usage of the tool. Look for our digest in the very near future.

- M

The challenge with Best Practices is that the current environment within the Enterprise may not be conducive for them: the technique may not mesh with existing policies or procedures, or the requisite skill set to execute the technique may not exist in the current enterprise. When a situation like this occurs, Real World Practices come into play.

A Real World Practice is the result of the intersection of a Best Practice and an environment that’s not readily conducive to them.

Two issues normally come to the forefront when Real World Practices enter the picture: many try to push a Best Practice through without heeding the environment around them to the point where it becomes more about executing the Best Practice than it is about resolving the problem; or they abandon the Best Practice altogether and go down a path that may not take into account the benefits of executing that Best Practice. It is too often at this point that many think that Best Practices won’t work in the Enterprise…trying to fit a square peg in a round hole if you will.

Remember, a Real World Practice is the intersection; a best of both worlds approach. It takes into account the benefits of the Best Practice approach, while trying to implement it within the guidelines of the environment they’re in. It’s not meant to replace a Best Practice: it’s an adaption of one given the environment it’s in. Familiarity with a tool like SharePoint, and the length and breadth of experience that LiquidHub has in implementing SharePoint Solutions in a multitude of Enterprises, allows us to evaluate the need of the implementation within the guidelines of the Enterprise, and resolve the need via a Best Practice, or a Real World one.

- M

Below is how I view the role.

A Web Architect is a specific type of application architect*.  A web architect is expert re: web-specific scenarios and technologies applying best practices, patterns, and reference architectures around delivering web-native experiences in one or more of 3 types of ‘web’ environments: 

§  Internet web sites;

§  Intranet web sites;

§  Web-enabled applications [i.e., exposing application functionality via a web browser]

A generic ‘web architect’ would have the following:

§  generic system and application architecture knowledge:

o   non-functional attribute analysis**; session and state management, caching design, security/identity management, instrumentation, smart client and mobile-to-web topologies, user experience patterns

§  ‘web’ / SOA conceptual skills:

o    e.g., , service-oriented architecture, peer-to-peer architecture, web browser design, W3C standards, web services APIs [e.g., SOAP, REST, POX]

§   ‘web’-oriented technology knowledge/skills:

o   e.g., XHTML, CSS, XML, content syndication and aggregation [RSS, ATOM] and web 2.0 technologies

§  ‘web’ application development platform experience:

o   Client-side AJAX Frameworks [e.g., Kabuki AJAX]

o   Server-side Frameworks [e.g., Ruby on Rails]

o   Other RIA Technologies [e.g., Flash, OpenLaszlo, etc…]

§  [optional] knowledgeable re: ‘web’-oriented’ rich user interface development environments

o   e.g., Abobe Flash, Flex, WPF

*An Application Architect is expert re: architectural best practices, patterns, standards, and reference architectures and typically has deep experience with one or more application platform technologies (e.g., JAVA, .NET)] 

** Non-Functional [Architecture] System Attributes:  Availability,  Conceptual integrity, Flexibility,  Interoperability,  Maintainability,  Manageability,  Performance [latency or throughput],  Reliability,  Reusability,  Scalability,  Security, Supportability,  Testability and Usability