Enterprise Initiatives

This Blog is Moving and a Comparison of Wordpress, Blogger, TypePad

madgreek65@gmail.com (Mike Kavis) — Mon, 15 Dec 2008 22:44:00 +0000

This Blog is Moving to a new Home!
This is the last post I will do on Blogger. I am moving Enterprise Initiatives to KavisTechnology.com. The material will stay the same but the landing page will be different. If you are a subscriber, you can get the new RSS feed here.

Why is the blog moving?
I started my consulting company this past June and created a new blog on my company's domain. That made my fourth blog that I have to maintain. When I started blogging a couple of years ago I started here on Blogger with the Enterprise Initiatives blog. After a month I discovered the ITToolbox community and started blogging there as well. I was going to move this blog to the Toolbox but Techdispenser started including this blog in their community. Then I was invited to write for CIO.com on their SOA Drilldown blog which I did for three months.

Although not all of my articles go on all three - blogger, ITToolbox, and KavisTechnology - most of them do. I wind up doing a cut and paste exercise everytime I blog. So to save some time I am going to cut it down to two blogs, the ITToolbox (generates a little revenue for me) and my company blog @ KavisTechnology.com.

Blog Editor Ranking
I would like to rank the three different blogging platforms that I have used. For this blog I use Blogger. ITToolbox uses Typepad and KavisTechnology uses WordPress.

#1 - WordPress - WordPress rocks! The administration panel simply blows away any other blog editor that I have used. I just upgraded to 2.7 with ease. There are thousands of plugins and templates available to use. In addition, there is such a huge WordPress following that you can find countless articles and even blogs dedicated to tips and tricks for blogging with WordPress.

#2 - Blogger - Blogger has a very nice editor and integrates easily with many Google owned products like YouTube, Picasaweb, AdSense and others. It has some nice templates but its administration panel is limited compared to WordPress. With Blogger I was able to easily integrate rich media content into blog posts. Blogger plugins are limited to what Google allows. Of course you can always add your own code but most bloggers prefer not to.

#3 - TypePad - My evaluation of Typepad is a little unfair. I believe that ITToolbox limits some of the funcitionality so that they can get hundreds of bloggers to deliver in a consistent format. We are not allowed to choose our own templates and they only offer a few plugins. The editor is way more cumbersome then Wordpress or Blogger which is why I cut and paste my code from WordPress into the other blogs.

I highly recommend WordPress as the blogging editor of choice!

Cloud Computing: Demystifying Cloud Terminology

madgreek65@gmail.com (Mike Kavis) — Thu, 11 Dec 2008 23:47:00 +0000

There is so much confusion (and fear) about what the term Cloud Computing means and what it really is. Now that everybody kind of "gets" SOA, the new buzzword that people can't grasp is Cloud Computing. Everyday I see the same questions being asked in LinkedIn like What is the difference between Cloud Computing and SaaS? A simple question like this will get 100 different answers. So this is my attempt to clear the fog on Cloud Computing in a simple non-technical way (sorry for boring those that already know this stuff).

Here is a picture that shows a high level view of different types of cloud computing

This picture is very basic but shows different types of companies leveraging the cloud model. You can also see that some types of computing are a subset of the cloud. Let's talk about the different types and what they represent (forgive me as I reuse some slides from a previous presentation).

First you have the Internet which we are all familiar with. When the Internet first became the buzz, a lot of the same confusion and fears that surround cloud computing today were being discussed back then. How is it secure? Who owns the infrastructure? How do I control it? Early adapters saw the opportunity to reduce costs by moving brick and mortar operations to the Internet and increase revenue by providing services and goods 24x7x365. This following picture shows some major web sites that leveraged the Internet (or should I say Cloud 1.0 to be hip).

Then came Software as a Service which was pioneered by companies like Google and SalesForce.com. With SaaS, instead of buying shrink wrapped software that you must install on your infrastructure, patch, administer, and do all of those other non-value added tasks, you simply "lease" the rights to use the services that are provided. In the case of Google and services like GMail, you get it for free.

Companies like Google, SalesForce.com, and Amazon have built out huge datacenters in multiple locations with an enormous amount of capacity. They cannot afford to have a huge spike of traffic take their sites down and risk losing millions of dollars a day. At some point, these companies realized that they could offer their excess capacity for a fee to other companies to use. These companies would be able to take advantage of world class production environments that are proven to withstand millions of concurrent users. This is what is known as Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). The difference is the platform.

PaaS providers like Google's App Engine and Force.com allow you to build your own applications on top of virtual server instances but restrict you to using their development languages. For Google it is Python, for Microsoft's Azure it is .Net, for Force.com it is Appexchange. One could argue whether Facebook should be classified as PaaS. I put it there because they now provide a full development platform for running applications on Facebook. Checkout this Facebook App by Starbuck's.

Infrastructure as a Service (IaaS) removes this limitation and gives you the ability to create virtual servers and develop in whatever you choose. The most popular IaaS vendor is Amazon who is in my opinion the leader in innovation and maturity in the cloud computing space.

So when people ask me what cloud computing is, I include all of these different models into my definition. "In the Cloud" to me means leveraging infrastructure off-premise. With SaaS solutions, the underlying infrastructure is hidden from you. With PaaS, you manage the amount of virtual server instances you use but you must use the technologies required by the provider. With IaaS, you manage the resources you use and are free to leverage whatever technologies you choose to deploy on.

Here are a few other useful resources that show a fairly complete list of vendors and the niche they fill.

Peter Laird - Visual map of cloud computing

Markus Klem - Cloud Classification diagrams

John Willis - Tools to use in the Cloud

John lists a number of vendors who provide a wide variety of tools to manage, configure, monitor, and scale including open source alternatives.

Check these resources out. I hope this gives you all a clear picture of what Cloud Computing is. The benefits and the risks are blog topics within themselves. I'll save that for another day!

An Agile Architecture Strategy

madgreek65@gmail.com (Mike Kavis) — Wed, 10 Dec 2008 04:38:00 +0000

I have been blogging for quite some time about SOA and Event Processing and have recently been getting more experience with Cloud Computing. The last few weeks I did a series of posts on agile SOA:

Today I completed a nice presentation on Slideshare called Agile Architecture which combines SOA, EDA, and Cloud Computing in a strategy to support the ever demanding needs of our dynamic business environment. I have the luxury of starting from scratch because we are in startup mode and do not have the burden of years of legacy systems and legacy cultures. The goals of our architecture are many, but here are a few key goals that speak to the topic of agile:

Must integrate with multiple customers, suppliers, partners
Must be configurable
Data may physically be stored in different locations for different customers
We don't own or want to own a data center
We want our customers/partners to be able to extend our services
We will deliver our software as a service
Each customer/partner has unique business processes and rules
We need to deliver our content on many different mediums and devices

I could go on but you get the picture. The reality is that we need to support an extremely dynamic business model and we need to be able to scale quickly. The following presentation shows the approach we will adopt to meet those requirements. This will be a long journey and will not happen overnight. But with a clear vision of the future state, we can plot a path of small manageable milestones to help us get there. I hope you enjoy the presentation!

Agile Architecture

View SlideShare presentation or Upload your own. (tags: soa bpm)

Podcast: SOA and Change

madgreek65@gmail.com (Mike Kavis) — Tue, 09 Dec 2008 23:56:00 +0000

Back in September I shared with all of you the presentation I gave about SOA and Organization Change Management. Today I am happy to share the podcast from that discussion that took place at the quarterly SOA Consortium meeting in Orlando. Here are the slides.

SOA & Change

View SlideShare presentation or Upload your own. (tags: soa change)

And here is the podcast that goes with it.

The panel discussion at the tail end of the presentation is fantastic. There were a lot of great questions and many lessons learned shared from experts like Todd Biske, Brenda Michelson, Fill Bowen from IBM, and others. If you have the time, listen to this podcast. Failure to recognize and counteract the resistance to change is the number one cause of failure for all enterprise initiatives, not just SOA.

Agile SOA: Empower the Business with Business Rules Engines

madgreek65@gmail.com (Mike Kavis) — Fri, 05 Dec 2008 13:45:00 +0000

If you have been following my blog recently you would have seen my previous posts that discuss the benefits of the various layers of the stack (mashups, data services, business processes). Although many IT folks talk about the benefits of SOA in terms of code reuse, the real benefit is in the ability for IT to adapt their systems at the speed that the business is changing. One of the best ways to accomplish this feat is to put tools in the hands of the business to empower them to dynamically alter the business rules as they change in real time.

In the old days we built systems with rigid rules and users were forced to adopt to the "laws of the system". Today, users are king and they expect systems to adapt to the way they need to use them. In order to satisfy today's tech savvy users we must build dynamic and customizable systems. We also need to make sure that IT does not become a bottle neck and hinder the rate of change that occurs within the business. The answer is simple, abstract the business rules into its own layer within the architecture and empower your users with the appropriate permissions to make the necessary changes in a timely manner.

Let's discuss the following order process example that I used in the post about business processes.

Now what if we had different rules on what a good credit score is? What if those rules were dynamic? Do we want to hard code these rules in the system and accept change requests from the business to every time they change or would we rather abstract them and give the business a tool to change them as needed? I'll vote for the later! Here is the same business process integrated with a business rule engine (BRE).

Here is a simple example of how the business can set up rules to apply different criteria to different customers.

In this example you can see that Gold customers get special treatment and will be allowed to proceed regardless of their credit score. Other tiers have higher standards applied to them. Now let's say that due to the credit crisis the company decides to apply stricter criteria on their customers and raise the minimum at each level by 20 points. The business can simply make these changes from the business rules engine interface which is most likely done from a browser. If the company wanted to add a Platinum user type, they simply add a record to the customer type table and the appropriate rule for Platinum customers in the BRE. Done! No change request, no priority setting, no change control board, no development, no testing, no rollout!

I also used a callout to point to a business rule lookup at the fulfillment process. Let's say that our company is an eCommerce seller for many different wholesalers. We may sell books, music, appliances, clothes, etc. but we are simply the middle man and don't own the inventory. Instead we sell, take a cut, and trigger transactions to the appropriate wholesaler for distribution. Each wholesaler has a unique set of business rules for their fulfillment process. In addition, we may add and remove wholesalers several times during the year. We have a standard business process for dealing with fulfillment but different wholesalers may have different rules due to industry specific or geographic requirements (age limitations, state laws, tax rules, etc.). Once again, an appropriate business person with the proper permissions should be able to make these changes as necessary without having to deal with IT.

Business rules have their place and purpose but they also come with some baggage. Like any other layer within the architecture, business rules need to be administered, maintained, and governed. Business rules need some level of change control, backup/recovery, and auditing like any other artifact. Most BREs either provide that functionality as well or hook up with other tools that manage artifacts (CMDBs, governance tools, etc.). But business rules are only worth the hassle if the business environment is dynamic. If the rules are static in nature, it is probably not worth the effort from an architectural stand point to create an abstract business rules layer complete with the appropriate security, auditing capabilities, etc.

The higher up the stack we go the more opportunities we create for the business to become agile. Business Rules create the ultimate flexibility and agility that most of today's businesses require. Implementing a BRE in your SOA is another great step towards IT becoming an enabler instead of a cost center!

Are IT Leaders Missing the Boat?

madgreek65@gmail.com (Mike Kavis) — Thu, 04 Dec 2008 03:40:00 +0000

I have spent a lot of time recently questioning the leadership of IT organizations who become a cost center due to a "keeping the lights on" mentality and have asked the question Are we Sleeping at the Wheel?. The other day I stumbled across a great article (thanks to some of my pals from Twitter land) that really hits the nail on the head. This is a must read article that brings to light what I think is the main reason why many IT leaders are missing the boat on emerging technology trends. The article is written by Steve Andriole is called Managing IT: Changing Our Minds (About Everything) and discusses how IT leaders who have been around a while have to let go of solutions of the past and totally change the way they think. Here are a few excerpts...

Here’s the deal. The world has changed – forever. First, hierarchical management structures will weaken as we continue to globally decentralize our business units. We have to change the way we think about control, standardization and the overall governance we bring to technology acquisition, deployment and support.

Here is his thoughts on Open Source which I have been championing for quite some time...

Open source is here to stay. Even the established vendors have “embraced” open standards. They have no choice. Do you?

And what about cloud computing?

We need to change how we think about cloud computing from an incremental shift in technology offerings to a whole new way of acquiring, delivering and supporting digital technology

Here is my favorite...

Debating endlessly about whether or not open software, cloud computing or SaaS have any merit is a waste of time – and most likely a diversionary tactic designed to slow – if not outright kill – the pace of change.

Please take the time to read the entire article. I think the message is an important one. If you are an IT leader who is missing the boat, you need to reevaluate your positions on the emerging technologies and solutions. If you don't you are damning your organization to more years of fire fighting and being a bottleneck to the progress of the business. Don't miss the boat!

SOA: Pay now or Pay forever

madgreek65@gmail.com (Mike Kavis) — Tue, 02 Dec 2008 16:59:00 +0000

An article written by Joe McKendrick called SOA eased the way for recent shotgun financial mergers inspired me to take this discussion one step further. To me, the biggest benefit of SOA done right is agility. I define agility in IT as the ability to adapt to change at the speed of business. Companies that invest in architecture, specifically in SOA, are in a much better position to adapt to mergers and acquisitions, connect to partners and suppliers, take on new business opportunities, and continually drive down the costs of maintenance and support.

I read many blogs and subscribe to numerous group discussions on SOA, EA, and cloud computing. There is so much discussion arguing the semantics, the ROI, and the viability of these technologies/architectures that it sometimes becomes discouraging. At some point we need to hike up our boot straps and invest in our business's future and stop fire fighting. Those companies that invest now (and do it right) will create a competitive advantage over those that do not. Here are just a few of the harsh realities that our businesses are faced with:

Decreasing margins
Fierce global competition
Mergers/ Acquisitions/ Consolidations
Recession
Demanding, connected, and empowered consumers
Increased regulatory constraints
Dynamic business requirements
Green initiatives

All of these things mentioned above are issues that we must deal with on top of our company specific issues and requirements that are far exceeding our capacity. To keep up with demand we need a flexible and agile architecture so we can make configuration changes instead of code changes, empower business users to change business rules instead of requesting expensive development projects, and leverage partner and supplier services instead of building everything from scratch, thus reinventing the wheel.

IT is only a cost center if the IT leadership allows it to be. The role of IT should be to innovate and help the business achieve its goals. IT must invest in strategies and architecture to allow this to happen. It is too easy to say we don't have the time, resources, and money. That's a cop out. As I have said before in my article The keeping the lights on mentality

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So IT leaders have a choice. They can refuse to invest in SOA and continue to support and maintain an inflexible environment that takes a lot of time and money to change or they can invest in the future by justifying an initiative to provide the business with flexibility, agility, and empowerment. Is it easy to do? Heck no! It requires talented staff and partners and most of all top level support. Ask yourself this question. If your company was to merge with your number one competitor tomorrow, how long do you think it would take to integrate these systems? If your competitor was buying your company and your systems were archaic and hard to integrate with, what do you think the odds are that they would keep you around? That's what I thought! Pay now or pay for it forever.

Why an Open Source SOA stack makes sense

madgreek65@gmail.com (Mike Kavis) — Tue, 25 Nov 2008 18:28:00 +0000

Dave Linthicum wrote a post today called Open Source SOA provides some major advantages. In his post Dave stated:

When it comes to SOA, I think open source provides two major advantages:
First, it's typically much less expensive than the tools and the technology that are proprietary.
Second, they are typically much more simplistic and easier to understand and use.
To the second point, simplicity. The open source SOA vendors seem to take a much more rudimentary approach to SOA, and their tools seem to be much easier to understand and, in some cases, use. While some people want complex, powerful tools, the reality is that most SOAs don't need them. If you're honest with the requirements of the project, you'll see that good enough is, well, good enough.

Great point Dave. I would also add another clear advantage which I learned the hard way. On a previous enterprise wide SOA initiative, I drank the cool-aid that the vendor stack was an integrated stack and was simpler to deploy and manage over a stack of a mix of vendors. What I found out is that the mega vendors (IBM, Oracle, etc.) have bought so many pure play tools (rules engines, BPMs tools, data services and MDM tools, governance tools, etc.) that the smooth integration ends when the Power Point decks are closed. In reality, the mega vendor stacks are a hodge podge of rushed acquisition and integration efforts. The underlying architecture of each tool within the stack are completely different and there are very few people (if any) within the organization who understands the complete stack. In fact, we were dealing with two very different organizations when dealing with support and they were not in sync. Eventually the entire company was consumed by another mega vendor (you can probably guess which acquisition this was) and the whole product roadmap was turned upside down.

Now let's look at some of the well established open source stack vendors like WSO2, MuleSource, and RedHat. These vendors do not suffer from acquisition madness and chaos. If fact, they are all built on a consistent architecture and do offer smooth integration between the various layers of the stack. Do they have all of the features of the commercial products? No. Do they have enough features for most SOA initiatives. Definitely. I wrote a post on CIO.com called Tight Budgets? Try open source SOA. Here is a quick summary of the advantages I discussed (read the article for the details):

Try before you buy
Lower cost of entry
Cost effective support
Core competency
For the people by the people

So what open source options do I have, you might ask? The following picture shows the open source tools that I prefer for my new SOA initiative. We are using a combination of WSO2, Intalio, Drools, Liferay, and PushToTest.

This is just one example of many. You can mix and match tools from different open source communities or you could standardize on one community. Here is an example of Red Hat's jBoss SOA stack.

And MuleSource has a well known suite of tools as well.

Many organizations are still not very comfortable with open source for mission critical initiatives. I have debunked many of the open source myths in the past (here, here, and here).

If there ever was a time to embrace open source, the time is now in this harsh economy. As commercial SOA vendors continue to get gobbled up by the mega vendors, it is time to seriously consider alternatives.

Agile SOA: The Flexibility of Business Processes

madgreek65@gmail.com (Mike Kavis) — Tue, 25 Nov 2008 02:36:00 +0000

As I have mentioned in many posts before, SOA built right can provide business agility and flexibility. Yesterday I discussed how to leverage data services and a few days back I discussed enterprise mashups. Today the focus is on business processes.

Separating business processes from code is an ideal way to build an architecture that enables systems to adapt more readily to change. Let's make believe that we are working for a large eCommerce site that sells many different categories of products from multiple suppliers and warehouses each with their own distinct business processes. Abstracting the business processes gives us some very important advantages:

Creates a set of standard business processes for a consistent user experience
Allows us to quickly bring on additional suppliers
Allows us to change a core business process once and apply it to all suppliers
Allows the business to make modifications to its processes with minimal or even no coding

Here is an example of an order fulfillment process.

This work flow speaks to my first point "Creates a set of standard business processes for a consistent user experience". The complexities of working with multiple suppliers, each with their own processes and systems is hidden from the end user. Regardless of what products the customer is buying and which supplier is fulfilling the order, the user experience is exactly the same. On the other side of the equation, bringing on a new supplier can be as simple as collaborating on a set of services to integrate the supplier's back end system to the core business processes of the eCommerce site. Had we not separated the business processes from the code, we would have to make modifications to our existing code base which is already running in production and would have to go through a complete testing cycle. Instead, we simply tell the business processes which set of new services to integrate with for the new supplier. All of the existing code is not impacted and does not need to be retested. Instead, we can just validate the new services and the new supplier flow.

Here is another benefit. Let's say that we just signed agreements with three new suppliers and have contracted to launch them all in 4 weeks. Without the separation of business processes from code, all three supplier integration efforts would have to be coordinated and most likely bundled into one build. This creates huge project risks because slippage in any one integration effort can delay all three. By separating the business processes from the code, each supplier integration can be implemented whenever it is ready. We can stub out a call for each supplier and assign the appropriate WSDL when the services are completed. For example, the "Fulfill Order" process could be an integration with SAP for supplier 1, PeopleSoft for supplier 2, a custom built fulfillment process written in Java for supplier 3, and a custom built fulfillment system written in .Net for supplier 4. The business and the business processes have no need to be concerned with the technologies behind the fulfillment process. They are only concerned with the inputs, the outputs, and the quality of service (QoS).

As we move up the stack it gets even better! Next post I will discuss the importance of business rules. Stay tuned.

Agile SOA: Leveraging Data Services

madgreek65@gmail.com (Mike Kavis) — Sun, 23 Nov 2008 16:48:00 +0000

The promise of SOA is flexibility and agility. I define agility as the ability to adapt to change at the speed of business. In today's global economy which has been fueled by collaboration and Internet technologies, businesses change at a much faster rate than ever before. So how does SOA help companies become agile? Let's look at a logical view of a typical SOA.

You can see in this diagram how each layer of the architecture has been abstracted and is mutually exclusive or "loosely coupled" from the other layers of the architecture. Why is this important? The answer is simple.....ease of change! Here are some advantages of this approach.

Share services, components, rules, etc. across the enterprise (reuse)

Isolate changes and reduce dependencies (speed to market)

Minimize impact of business changes (speed to market)

Easier to maintain (maintainability)

Let me give an example of how this approach helps companies become agile.

Use Case: New customer data from a new client

Let's say your company provides a service for customers in the retail industry. You have a website that offers online services for consumers and your white label solution is tailored to look like it is hosted by the individual retailers. The problem is that each retailer has their own customer database. In the past you would have to write a ton of code for each retailer that you signed up to use your services. With SOA, now it is a simple data mapping exercise. By abstracting data services, the other layers of the architecture use the logical representation of customer, not the physical implementation. Behind the scenes, the data services layer is translating the request for customer data from logical view to physical implementation. So when you bring on new clients, you simply use a tool in the data services layer to map the new clients customer data to the standard logical definition as defined by the architecture.

You can see from this example that all three retailers have an entirely different implementation of their customer database including different naming conventions and even different attributes. In the data services layer, you can map all of these physical implementations to one standard customer definition. You can also see how the business processes all use the logical view of customer. This allows us to add and change customer definitions on the back end without changing code on the front end. If two more retailers were to sign up tomorrow, we can map their definitions to the logical customer view and be done. No Code!!! That is agile!

I will give examples of agility within the other layers in future posts. If you would like help establishing a data services strategy, give me a shout!

Enterprise Mashups - The Icing on your SOA

madgreek65@gmail.com (Mike Kavis) — Fri, 21 Nov 2008 15:16:00 +0000

The Dilemma
I have been spending a lot of time recently learning about enterprise mashups. The new startup that I am working for is building a SaaS solution that will be consumed by various types of customers and partners. These customers and partners may want to consume our data services as a RSS feed, gadget, SMS message, web page, within a portal or portlet, or a number of different ways. I do not want to spend the rest of my life developing new output mediums for our services. Instead, I would rather spend my time adding new business services to enhance our product and service offerings hence contributing to the bottom line.

Enterprise Mashups to the rescue
Enterprise mashups will allow me to offer my partners and customers the ultimate flexibility to access our products and services in ways that are convenient for them without having to wait on my IT shop to decide if (a) we think the request is important enough in our priority list, (b) if we have the time and resources to work on it, and (c) how much we will charge them. On the IT side of the house, with an enterprise mashup strategy in place we can be assured that whatever mashups our customers and partners create, they will be subject to the same security and governance as the services we have developed. The diagram below shows a logical view of how our SOA will be designed.

As you can see, we have clearly abstracted the various layers within the architecture and they all inherit our overall security policies. SOA governance is applied to this architectural approach to enforce our standards and design principles. Overall IT governance provides oversight over the entire enterprise which includes legacy systems (we don't have any legacy yet), third party software, etc.

Now let's add the enterprise mashup layer. We want to hide the complexity of our architecture from the end user and expose data services to them to consume. At the same time we want these mashups to be equally secure as the services we write and adhere to the same governing principles. Enterprise mashup products provide tools to make managing this layer easy and efficient. The diagram below shows the enterprise mashup layer inserted into the architecture as a layer on top of SOA.

From SOA Slides

Enterprise Mashups in simple terms
If the concept of Enterprise Mashups is still not clear, check out this white board discussion with JackBe's CTO John Crupi.

I spent some time talking to JackBe's VP of Engineering Deepak Alur a few week's back. Deepak discussed how enterprises have been focusing more on infrastructure and technology and not on the consumers of data. As he coined it, many shops are "developing horizontally and not addressing the needs of the users". He talked about how users were doing their own brute force mashups by cutting and pasting data from various places into Excel. This creates various issues within the enterprise due to lack of data integrity, security, and governance. It is ironic how corporations spend huge amounts of money on accounting software and ERP systems, yet they still run the business out of user created Excel spreadsheets! The concept of enterprise mashups addresses this by shifting the focus back to the user consumption of data. Here are some of the requirements for mashups that Deepak pointed out to me:

User driven & user focused
Both visual & non-visual
Client & server side (although most are server)
Plug-n-Play
Dynamic, Adhoc, Situational
Secure & Governed
Sharable & Customizable
Near zero cost to the consumer

Jackbe's enterprise mashup tool is called Presto. Presto is an Enterprise Mashup Platform that allows consumers to create "mashlets" or virtual services. IT's role is to provide the security and governance for each data service that will be exposed for consumer use.

Presto Wires is a user friendly tool to allow users to create their own mashups by joining, filtering, and merging various data services (as shown in the picture below).

In this example the user is combing multiple data points from many different organizations in an automated fashion. They could then present this data to multiple different user interfaces and devices. All without waiting on IT.

Here is a simple example of a mashup of Google Maps with a Carpool data service.

The folks who create the Carpool data service where able to leverage the Google Maps service without having to write their own mapping software and without having to know the underlying architecture behind Google Maps.

How this solves my Dilemma
Back to my dilemma. By leveraging a tool like Jackbe's Presto or WSO2's Mashup Server, I can now present various data services in a secured and governed fashion to my customers and partners without being concerned on how they want to consume it. Whether they want the mashup on their own intranet, as a desktop gadget, as an application on Facebook, or what ever they dream of, all I need to be concerned with is the SLA of my data services. This also makes my product offering more competitive than my competitors who have proprietary user interfaces that do not provide the flexibility and customization that the customers desire. As I said in the title, this is the Icing on your SOA cake. For those organizations who are disciplined enough to implement SOA and follow the best practices of design and governance, the reward can be an simple addition of an Enterprise Mashup Platform on top of your SOA stack. This is the ultimate flexibility and agility that SOA promises.

The future of IT: Are we sleeping at the wheel?

madgreek65@gmail.com (Mike Kavis) — Thu, 13 Nov 2008 00:16:00 +0000

As I look out into the future of IT over the next 5 to 10 years, I see a huge shift in how IT shops will need to operate in order to help their companies survive. We are already well aware of the pressing needs for IT to provide agility and flexibility for its business partners due to the speed at which the business landscape is changing. The forces of globalization, economic pressures, and advancements in technology are creating as much change in an 18 month period than we used to experience in a decade. In order for companies to survive and thrive, they need to adapt. As Charles Darwin once said,

“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”

I wrote a post last year called How did we become a Dilbert cartoon which discussed my theory on how IT has become so out of touch and bogged down with trivial issues. I see Dilbert every day whether it is at the places I have worked, the case studies that I research, the discussions I have with peers at conferences, or from the forums and user groups I participate in. Somewhere along the line, many IT professionals in the US have forgotten what IT's purpose is and take their IT profession for granted. These people put themselves and their favorite technologies first and their business and shareholders second. How many important initiatives have you seen stalled because certain individuals refused to change or learn something new? Look how many companies are struggling implementing transformational initiatives like SOA, ITIL, business process reengineering. All of these types of initiatives can make a huge impact to the bottom line. But how many of these have stalled because people fought these initiatives with all of their might? The basic problem is that transformational initiatives requires transformational leadership! How many leaders within IT do you know who excel in the three critical areas of transformational leadership required to deliver technological solutions: Business Acumen, People & Organizational Skills, and Technology skills?

From Misc IT

Looking down the road, I see certain technologies maturing and becoming critical to helping businesses staying competitive. These technologies are:

Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Social Networking/Software within the enterprises
BPM, SOA, and Event Processing working in harmony

I am amazed at the number of pundits that exist for all of these technologies, especially cloud computing. Many people are strongly against these advancing technologies at the expense of their own careers (they just don't realize that they are making themselves the equivalent of Y2K programmers yet). Sure, cloud computing has its challenges with data security, privacy, and in some cases reliability, but it is in its infancy state. Instead of focusing on what the limitations are, we should focus on the huge strategic and financial opportunities that it creates. Let me quote Darwin again.

“Ignorance more frequently begets confidence than does knowledge: it is those who know little, and not those who know much, who so positively assert that this or that problem will never be solved by science.”

I still remember the naysayers doubting PCs and distributed computing and declaring that nothing could beat the mainframe. Do you here the negatively by some about social networking and social software? Doesn't it sound like the negativity we heard when people were trying to bring the Internet into corporations?

Why do we get in our own way of progress? Why are we living in Scott Adam's world of Dilbert? Why do system administrators fight cloud computing? Is it fear of job elimination? Loss of control? Not wanting to learn something new after 20 years? Why do IT professionals revolt against SOA? Does it require them to actually architect something rather than drag-n-drop some code in their favorite Microsoft IDE? Does it force them to collaborate with other people including business people and take them out of their comfort zone? Is it hard work? I don't know what the answer is but I do know that with out transformational leadership, the resistance can put up huge barriers and can kill initiatives that can give a company an edge over its competition.

What about outsourcing? Do you really want to get IT professionals fired up? Just the mention of the word brings anger and negativity to many. But why? Maybe we all need a lesson in economics or should simply read the book The World is Flat. While we in the US are sitting here complaining about change, countries like China, India, Taiwan, Ireland, and many others are graduating engineers by the thousands. These folks are more than willing to work on any task that they have the privilege to be given. And there lies the problem. To these people, work is a privilege, a way to have a better, more prosperous life. In the US, many people see their job as something that is owed to them. How many people in your shop are actively working on improving their skills? Just the fact that you are reading this post puts you many steps ahead of most. Many people that I have worked with in my 23 years do not invest their own time and energy required to continue to learn and adapt to the world around them, both from the technology and the economic standpoint. I am fine with the fact that many people value their personal time way more than some of us do, but if you don't invest the time you do not have the right to impede in the advancement of the organization!

Getting back to the emerging technologies that I mentioned above. To be successful implementing the transformational change to embrace these technologies, IT shops need the following foundation:

Strong leadership with the ability to promote and manage change
A well run and planned Enterprise Architecture
Solid working relationships and trust with the business partners
Discipline
Fiscal awareness
Numerous Strategic Partners

Strong Leadership
The leader(s) must be visionary, strategic, emotionally intelligent, and must be able to execute. I have seen leaders who have great ideas and are pretty smart, but they fall down when it comes to execution. Nine times out of ten, the failure can be contributed to people not the technology. In other words, resistance to change prevails and the company reverts back to the status quo leaving IT with the reputation of a cost center. The following presentation speaks to how to anticipate and plan for change up front to reduce the odds of failure.

Managing Change in a Business Transformation Environment

View SlideShare presentation or Upload your own. (tags: architecture governance)

Enterprise Architecture
To enable a flexible and agile enterprise, it all starts with an architecture that maps to the overall business strategy. No longer can we afford to build software in silos and continue to pay huge sums of money to keep the lights on. In order to be efficient with our ever shrinking budgets, we must have an IT strategy that is supported with an architecture geared towards maximizing our resources (both human resources and technology resources). The more standard and consistent the architecture is, the easier a company can move to the clouds, alter business processes in days instead of months, change business rules on the fly, adapt to mergers and acquisitions, and connect to partners, suppliers, and customers. Remember this, your biggest threat tomorrow might be a company that does not exist today! Why, because a startup does not have legacy to deal with and will most likely embrace these new technologies from the start and race right by you to the finish line. Companies must change or die. The following presentation speaks to the value of EA.

EA Vision 4 24 08

View SlideShare presentation or Upload your own. (tags: enterprise architecture)

Relationships and Trust
In order to accomplish transformational initiatives, IT must forge great working relationships with its business partners, both internally and externally. Without the trust, funding and executive level support will be extremely hard to come buy. To earn that trust, IT must understand the business and put forth solutions that are beneficial to the business first and IT second. The following presentation shows an example of how SOA was explained to the business in tangible business terms (increase sales, customer satisfaction, etc.) instead of technology terms (reuse, ESBs, services, etc.).

Practical Soa - Kavis

View SlideShare presentation or Upload your own. (tags: soa bpm)

Discipline
This is critical. We can no longer fly by the seat of the pants anymore. It costs the company too much in maintenance and hinders agility. That is not to say that we should all embrace heavy methodologies like CMM. There needs to be the right balance between process and agility. And for those IT professionals who will fight process to their death beds, there are millions of knowledge workers in foreign countries hungry to do your job for you. Today's resistance is tomorrow's unemployment.

Fiscal Awareness
Being fiscally aware is a key contributing factor to allowing IT professionals to see the "big picture". After all, the main purpose of most companies is to make money, or in government, to make the best use of tax payer dollars. It's all about money! So why are so many IT professionals so clueless about the financial impacts of the work they do and the decisions they make? How many times have you sat in meetings with armies of people for an hour or two and nothing gets accomplished? How does that contribute to the bottom line. When technologists argue about .Net vs. Java, or IBM vs. Dell for months on end while projects get delayed, why doesn't anybody seem to care? When IT professionals make technology decisions primarily for the sake of technology, they often make a choice that is not fiscally responsible. When making these decisions we must think about more than how we will use the products within IT. There are many factors that need to be consider. We should look at the feasibility not just from a technical standpoint, but also from an economic, operational, and political standpoint as well.

Strategic Partners
And finally, there is so much change and so much to learn, it would be suicide to think that we could deliver anything transformational in a reasonable amount of time without the help of partners. The business can't wait for IT to train an entire staff to a high level of competence on these emerging technologies. They also can't wait for us to stumble and learn from failing in production. Instead we will need strategic partners in many areas to help build the agile enterprises of tomorrow. These partners may be used for the following reasons:

Business Process Outsourcing (BPO) - (example: Payroll, HR, web site hosting, etc.)
Acquire new skills (SOA implementers, BPM experts, Cloud specialists, etc.)
Strategic partners (Organizational Change Management expert, EA help, etc.)
Technology outsourcing (IaaS, PaaS, SaaS, etc.)
Project based outsourcing

Outsourcing does not mean the same as offshoring and outsourcing does not always relate to development. When cost is an overriding factor offshoring is a no-brainer. Of course without EA and discipline, outsourcing may cost more than expected. There is simply too much to do and so little time to do it. Find the right partners and hold them and yourself accountable for transferring the knowledge to members of your staff.

Summary
I apologize for the length of this post (if you made it this far). I am very concerned for the future of my IT colleagues in the US and had to do a "core dump" on this post. After many years of prosperity, many IT professionals in the US have become intellectually lazy and blind to the opportunities and challenges that this new economy has created. The combination of our financial crisis coupled with the forces of globalization and technological advances will create radical changes over the next decade. Many professionals are too wrapped up in reality TV to realize that the world is catching up and is ready to pass us by. Those who understand that can embrace the new opportunities that these conditions will create. The others will be the equivalent of the Y2K programmers who did not embrace the post 2000 innovations. I'll leave you with another great quote from Darwin...

“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed"

Managing Change in a Business Transformation Environment

madgreek65@gmail.com (Mike Kavis) — Sat, 08 Nov 2008 03:39:00 +0000

I was invited to speak at a forum for IT executives in Detroit this week sponsored by Information Week. The purpose of the forum as described in the agenda goes like this...

This executive breakfast, specifically designed for senior business-technology executives, will explore why the pressure is on IT to help the business transform, and how it can meet those expectations. More than ever before, companies are demanding their CIOs to be strategic thinkers in helping them innovate and operate at peak performance - especially as businesses are under pressure from the poor state of the economy and the ever-faster pace of change in a global market. In this environment, you can't miss this opportunity to gain insight into the tactics and strategy that will help you be on your best game.

I was specifically asked to talk about why transformational IT initiatives like BPM & SOA fail and what advice I would offer to prevent failures from happening. I put together the following presentation which is a combination of some of my previous presentations, Preparing for SOA and SOA & Change.

Managing Change in a Business Transformation Environment

View SlideShare presentation or Upload your own. (tags: architecture governance)

I wrote a very popular article on CIO.com a while back about the Top 10 reasons why SOA fails. I speak to each of these points in the presentation and present solutions for each. I also discuss using John Kotter's 8-step process for managing change which I highlight in the presentation. Here are my keys for preventing failures.

Plan for and manage organizational change

Key drivers should be business focused not IT focused

Evaluate internal skills and fill gaps. Do not try it without help!

Don't let the vendors drive your architecture. Do your homework.

Grow your governance model over time

Speaking of governance, here is an analogy I like to use...

Implementing SOA without a solid governance model is the equivalent to having an airport without a control tower. Sure, there are some very good planes and talented pilots, but without the proper planning and timely information the end results would be disastrous. So make sure you build a control tower and hire some air traffic controllers!

If you would like me to create and present a custom presentation like this one, feel free to contact me

Betting on Social Networking, Literally

madgreek65@gmail.com (Mike Kavis) — Tue, 04 Nov 2008 16:17:00 +0000

I am a huge fan of social software, especially when it comes to networking with experts in technology. Those of you who follow me on Twitter know that I am a fanatic NY Giants fan who travels from Florida to hostile stadiums in places like Dallas and Pittsburgh to watch my beloved GMen go to battle. Last week, Jordan Haberfield, an expert at finding and placing talented SOA technicians at major corporations, asked me about a wager on the game between the Giants and his favorite team, the sell proclaimed America's Team and arch rival Dallas Cowboys. My normal bet with friends is for lunch or a few beers. Since Jordan is in New Jersey and I am in Florida, that bet did not make sense. What did make sense was betting that the loser would have to post a congrats on his blog.

Well, that was like taking candy from a baby as the Giants put a thumping on the depleted and heartless Cowpokes. To see Jordan pay his debts, go to his website called Agile Elephant. Jordan did manage to find a picture of one of the few positive plays that his Cowboys had in the game. My favorite Cowboy moment is still the Terrell Owens "My Quarterback" crying session after the Giants knocked the 'Boys out of the playoffs last year.

So add wagers to your list of things you can do with social software. It's the gift that keeps on giving and is searchable on Google!

SOA Testing: A discussion with iTKO's John Michelsen

madgreek65@gmail.com (Mike Kavis) — Mon, 03 Nov 2008 18:17:00 +0000

A few days ago I had a chance to catch up with iTKO's co-founder and "Chief Scientist" John Michelsen to discuss SOA Testing. For those of you unfamiliar with iTKO, they produce one of the industry leading SOA testing products known as Lisa.

I have been writing about SOA testing a lot lately and the folks at iTKO contacted me after I wrote Six Questions to Consider before Building a SOA Testing Team on CIO.com. Since this article was fresh on my mind, I asked John some of the same questions that were posed in the article.

My first question to John was to identify some of the characteristics of successful SOA implementations he has seen from his customer base. Without hesitation, John pointed to customers that integrated testing into the development cycle. Successful SOA implementations tend to shy away from old waterfall methodologies and involve QA early in the life cycle. In many cases, testers work side by side with developers. John mentioned that "development builds things from scratch, QA does not". He pointed to this three step process which is the trademark of successful SOA testing:

Development builds the testing framework
Development builds initial test cases
QA enhances the test cases

Steps 2 & 3 is an iterative process and requires good collaboration between development and QA. This advice is similar to what I recommend in my article SOA Skillsets: PArt 4 - The Testers. In this article I recommend that a Test Architect be part of the EA team and design the testing framework and strategy. This person needs to be extremely technical and have a deep understanding of SOA concepts. The test leads also need to have a thorough understanding of SOA while the remainder of the testing team does not need to be as strong technically. However, they do need to be able to write some code as the developers hand over their test cases for refinement.

I asked John how technical the testers need to be. He stated that "most QA folks are still business analyst types and it should stay that way. If QA gets too technical then they lose the focus on testing". I agree which is why I advocate having the Test Architect as a member of the EA team focusing on building out the framework, evangelizing, and training the QA team.

I asked John about the importance of testing tools. He stated that the "Testing tools need to let less technical people perform technical tasks". This is a good point because your testers need to more focused on validating that the business and technical requirements are met than figuring out how to master a new tool.

This last point led us to a discussion about iTKO's Lisa products. John mentioned that they have just released version 4 which has many new features. In addition to the core product, Lisa Enterprise, the Lisa Server product has two new important modules, Continuous Validation Service (Lisa CVS) and Virtual Service Environment (Lisa VSE). Lisa CVS addresses the challenges of integration testing, deployment issues, and validation of governance compliance. Anybody with experience in SOA will tell you that the distributed and loosely coupled nature of SOA adds a whole level of complexity in the areas of builds and deployments.

Lisa CVS helps manage and automate some of those complexities and takes a more proactive approach to management and governance by allowing you to "revalidate expected behavior". Lisa VSE takes advantage of virtualization technologies so that you can create images that can simulate behavior of your heterogeneous environment. They accomplish this by installing agents on your various environments (mainframes, database servers, web servers, etc.) which allows VSE to monitor and emulate performance by creating a server side model of your production environment. This model can then be deployed in a virtual testing environment and be tweaked to simulate various scenarios such as abnormal spikes in traffic, simulating new customer loads, or whatever scenario you wish to entertain.

John was real excited when he talked about version 4.6 that is due out towards the end of the year. In this release, Lisa will add functionality to allow customers to test stateful services. This has been the missing link in SOA testing up to this point. John also mentioned that Lisa is now integrated with all major registry and repository tools. In addition, Lisa is also being used for Web 2.0 testing due to the work they have done with web services and WS-* standards.

In summary, testing is a critical component in the quest to launch and implement a successful SOA. By creating a well thought out testing strategy that includes tools to automate and simplify testing, organizations can focus more on the business side of SOA and less time focusing on the technology side of the equation.

Book Review: SOA Governance by Todd Biske

madgreek65@gmail.com (Mike Kavis) — Sat, 01 Nov 2008 17:45:00 +0000

My friend and colleague Todd Biske has recently published a must read book about SOA Governance. Most books that discuss process can require a ton of caffeine in order to make it from cover to cover. Not this book! Todd uses a unique style of combining a story of a fictional company along with his well served advice. He walks us through a multi year SOA project with a fictional insurance company called Advasco. Advasco, like many of the companies that we work for, has years of silo legacy applications that are the direct result of acquisitions, mergers, and years of developing in silos. The goal of their initiative was to "provide sales agents and marketing staff for the insurance division with a single view of the customer".

Todd takes us through the evolution which spans five years. Over this time, you can see the company make continual strides towards the overall vision but not without challenges. With each challenge comes another opportunity to mature their governance model. At the end of the book, Advasco's IT staff have made a major impact to the company's bottom line and ability to react to market changes. This is one of the few books that actually shows us what success looks like. This is why the book is so good. Many books talk about processes, structure, and controls but fail provide us with a glimpse into what the fruits of that labor looks like. Todd takes us from project inception, to successes, to set backs, to mitigation strategies, and ultimately to enterprise wide success. By taking us through this journey we can get a better understanding of the impact of the recommendations that he makes for SOA Governance. I won't go into details on what he recommends. I will let you read it yourself. But I can guarantee that you will enjoy the book and will be able to relate your real world experiences with the experiences of the fictional characters who helped move Advasco forward by leveraging SOA.

What made Advasco successful?
If you follow everything that Todd recommends in this book, you still are not guaranteed success. There were some specific events and characteristics that made this journey a success. Here is a short list:

Initiative was driven top down
Very little resistance to change
Great working relationship with business and IT
Very talented staff that was willing to learn
Effective EA team
Project was business focused

Final Thoughts
SOA Governance is a must read for any company preparing for SOA or for companies struggling to make their SOA initiative successful. Follow the advice and examples that Todd provides but also address the bullets I listed above. If you have the great staff that Advasco has you will find success. But in the real world, the effort to promote this type of change in the enterprise will usually require much more focus on change. At the SOA Consortium meeting last month in Orlando, Todd provided us with a great presentation about SOA Governance. I followed that up with this presentation on change.

SOA & Change

View SlideShare presentation or Upload your own. (tags: soa change)

If you focus on Organizational Change Management and heed Todd's advice on SOA governance, your odds of succeeding with SOA will be greatly enhanced. Buy the book, it is the best book on governance that I have read so far.

Are you smarter than a 5th Grader?

madgreek65@gmail.com (Mike Kavis) — Fri, 31 Oct 2008 02:17:00 +0000

A little off topic today.

Each evening I help my kids with their homework. They are both very capable with computers. My daughter has been blogging about her pets since she was 8 (she is 10 now). She creates blog entries complete with multi media with no assistance from me. Other than creating the Blogger template for her, all of the work is her own. My son is the wizard of Wikipedia which he discovered on his own a few years back. The fact that my kids are computer savvy gives them a huge advantage when it comes to learning.

For example, my son has a weekly technology project where he must report on how certain technologies work. Like me, he is fascinated by how things are manufactured. So each week we pick an item that we are familiar with and he Google's it. Then we find a video on the manufacturing process like the one below about how bubble gum is made.

This is so much more effective than how I had to learn. I was forced to use either an outdated encyclopedia that my parents purchased or I had to go to the town library. Neither of these experiences offered rich media options. I often had to perform a ton of reserach to get the desired knowledge in order to write my papers. My son and I are able to knock these weekly assignments out in a half hour. At the same time he gets to see the actual manufacturing process in the video which enhances the learning experience. Then he notices similar videos and starts learning how marbles are manufactured.

It is so obvious to me that this generation can consume large amounts of pertinent information in short periods of time. My kids are very up to speed on the current election process and even know who the Governor of Florida is. I am not sure I knew who the governor of NY was when I grew up there in high school. This is the beauty of Web 2.0 and Internet technologies. The whole ranking, tagging, and social networking processes that are taking place are allowing my kids to learn about the world around them.

Here is another great example. My daughter gets assigned a science project. So I am prepared to carve out numerous hours each night to help her get this done. Instead, I see here collaborating with classmates on Google Talk and exchanging links and images. She would draft a story board on paper, scan it, and send it to her classmate. I was floored. She completed the entire project without my help using free collaboration technology on the web. And she's 10 years old! So I ask myself. Are you smarter than a 5th grader?

Business Intelligence meets SOA

madgreek65@gmail.com (Mike Kavis) — Wed, 29 Oct 2008 00:37:00 +0000

Tomorrow at 4pm I am presenting at the annual EDM Summit in Orlando on the topic of Business Intelligence as a Service. Check out the presentation below.

Bi As A Service 9 19 2008

View SlideShare presentation or Upload your own. (tags: soa business)

This presentation is based on a real life project that I once worked on. We had a scenario where the business had a very complicated set of business rules required to determine what inventory was available to sell. Inventory for a loyalty marketing company is very dynamic and is not a physical thing like a widget. Instead it is a data mining exercise comprised of many "What-if" scenarios.

The old way of doing things was to get data from many different sources, some from systems, some from spread sheets, and some from somebody's head, and go through an ugly and error-prone process to determine what was available to sell. The process took many days which puzzled the customer why we couldn't tell them right away if we could run the program or not. Through some analysis, we defined new and improved business processes and data services that would allow our sales people to enter numerous parameters on a new web UI and let the systems return information to the screen with potential sales opportunities.

When the designers brought their solution to the architecture team for review we saw a huge opportunity to change the approach that was being recommended for the user interface. The designers were Java guys so naturally they recommended a Java web based UI (which infuriated the .Net community). But as I looked at the multiple screens that they story boarded it became obvious that building a what-if type UI was not best served by building proprietary code. Business Intelligence tools make a living doing just that. So I put a hold on the design and recommended that we brought in our BI partner for a proof of concept.

To make a long story short, we proved with our BI partner, that we could leverage the BI tool to create a robust what-if style GUI which we could talk to all of the layers of our SOA (see slides for details). In other words, we abstracted the BI tool as our presentation layer. What that gave us was all of the bells and whistles that come with BI tools like:

Flash enabled output
Subscription services
Mobile capabilities
Alerts
Great scalability
Logging
and much more

All of these things I mentioned above were out of the box features of the BI tool that we did not have to code in Java. In fact, we offered to the business a much more efficient solution. Instead of submitting data and reviewing rows on the screen, we offered to automate the business rules and allow them to subscribe to categories. This means that they only needed to go to the system to tell it what to look for and the system would alert them when categories were available. Now they could go into a sales meeting knowing in advance what was available to sell. When certain categories became available they could get an alert and immediately schedule a call to the appropriate customer. A future step could be to tie the alert into the CRM system.

So the key point to this story is that you can leverage BI as an abstracted layer within your SOA which will help maximize the value of your existing BI investment.

The "Keeping the Lights on" mentality

madgreek65@gmail.com (Mike Kavis) — Thu, 23 Oct 2008 16:44:00 +0000

I just read Dave Linthicum's post on SOA World titled Should you Fire your CIO? This is a continuation of a discussion that has been brewing in the blogsphere for the past few months that started after the Burton Group commented that a new CIO was often a key ingredient for some successful SOA implementations.

To successfully implement enterprise wide SOA initiatives, strong leadership is required at the top of IT. The person must have integrity, creditability, technical and business know how, and must be able to lead the organization through the resulting shifts in cultural values. The problem is, as Dave points out in his article....

....in many organizations the role of CIO has resolved itself as the person who keeps things running, not the agent of change.

I call this the old "Keeping the Lights on Mentality". When IT stops being an enabler and simply acts as a cost center or a "necessary evil", then entertaining new projects that leverage one of Gartner Top 10 strategic technologies is unrealistic and doomed for failure or hardship at a minimum. Why? Because this mentality is reactive and sometimes even defensive. This mentality also does not encourage investing in the future whether that is in training employees, establishing and investing in architecture, or addressing problems with long term solutions. Instead, people are rewarded for quick fix fire fighting heroics and at the end of the day it is the user community that suffers. The users get band-aids on top of already outdated systems and are often forced to work in ways in which the technology and systems dictate, instead of the other way around.

It gets worse for the employees in an IT department in charge of "keeping the lights on". Their resumes become stale as their skills are not updated to reflect the newer technologies that innovative companies seek. The reactive nature of the culture can squash innovation and people who have valid solutions may not bring them forward because it would require more than a quick fix. In the end these types of shops become like an assembly line in nature where people clock in, work their shift, and clock out. This is not what must of us envisioned when we enthusiastically enrolled in IT related curriculums in college back in the day.

The key business driver in a "keeping the lights on" shop is minimizing costs (usually over anything else). Which makes me wonder why more shops in this mode do not go down the outsource IT path. If lower cost is so important and large innovative initiatives are typically out of the question, why not radically lower the cost by outsourcing IT? I am not recommending that IT shops do this, instead I recommend that IT shops become good business partners and enablers of business success. But if I was a CEO or CFO and my IT's sole purpose was to be a cost center to keep the lights on, I would try to drastically reduce that cost. After all, keeping the lights on is not a core competency of most businesses. It is a necessary evil. Having hordes of full time staffers and paying for their benefits, stock options, and bonuses just to keep the lights on is not smart business. I know my view here will not be popular with most IT folks. I am not down playing anybody's abilities here. All I am saying is that if we don't need our staffs to be innovative, proactive, and be advocates of our business partners and instead just want to the staff to think short term, there is a much cheaper model out there.

So to answer Dave's question, if the business wants IT to help the business achieve its mission by being proactive and innovative and IT is simply keeping the lights on, the answer to his question might be yes. If the business simply needs a low cost IT cost center, the answer may be to evaluate the outsourcing model. Keeping the lights on as a core IT function and doing it at a high cost is just not good business. That's my 2 cents.

Disclaimer: In no way is this article referring to or targeting any organization or individual that I have been associated with in my career. This is a generalized view that combines my own experiences with the experiences of thousands of other IT professionals that I have talked to, read about, or researched throughout my 20+ years in IT.

Book Review: SOA Cookbook

madgreek65@gmail.com (Mike Kavis) — Thu, 23 Oct 2008 14:23:00 +0000

Packt Publishing recently asked me to review a copy of Michael Havey's new book, SOA Cookbook. I finished the book yesterday and really enjoyed reading it. This book is made for technical folks, so non-technical managers and drag-n-drop programmers should not waste their time. Michael Havey takes a really neat approach in this book to assist architects and developers to understand the concepts of SOA and process modeling. In each of the nine chapters, Michael discusses pertinent patterns, use cases, or disputes and then offers very clear and easy to understand examples of what the resulting models would look like. He also goes one step further and shows specific examples within each of the following vendor stacks (IBM, BEA, Oracle, and Tibco). I find this extremely helpful for technicians who are modeling processes in an SOA for the very first time. He even provides a URL
to download the sample code.

One of the most important points in this book and one that I totally agree with is that the typical three layer SOA stack that most vendors offer is "unmistakenly process oriented. There are processes at each layer". This is obvious in the BPM layer. Michael goes on to discuss how ESB processes are single-burst stateless processes and how orchestration processes are both stateless and stateful. So why is this important? Michael states that "it is easier for developers to model a service as a process than to code it explicitly in a third-generation language". Another important point is that since SOA is a business driven architecture and business analysts and business people are more comfortable looking at use cases and process models, technicians need to start thinking in these same terms. After all, "Bad processes mean bad SOA" as Michael concludes.

The remainder of the book dives into topics such as design decisions on whether a process belongs in the BPM layer or within the lower SOA layers, modeling using BPMN & BPEL, design decisions for both short & long-running processes, using the "Flat-Form" method of modeling processes, dealing with dynamic processes, Simulating SOA, and concluding with measuring SOA complexity.

Some key points worthy of mentioning:

A very worthy discussion of simulating SOA performance takes place in chapter 8. Michael recommends that simulation occurs before a line of code is written. When this does not take place it raises the risk of performance surprises in the production environment which may or may not occur right away. When these issues occur in production, resolving it becomes extremely expensive and can have catastrophic impacts.

The Flat-Form method of modeling processes is a must read. I won't spill the beans here but the methods intent is to flatten the process models to improve maintainability and simplicity. Great stuff!

Overall, I really enjoyed the book. I have read a ton of books on SOA and most of them are high level discussions on what SOA is and how to get started. This book picks up after those discussions and is a great tool for architects and developers who have to actually build and deliver SOA. I highly recommend it! I also recommend that your testing lead reads the book as well. If you don't have a tester who understands the content of the book, you better get one!

Next up is my colleague Todd Biske's SOA Governance book which I will finish reading this weekend!

SOA Skillsets: Part 4 - The Testers

madgreek65@gmail.com (Mike Kavis) — Wed, 22 Oct 2008 15:35:00 +0000

I have discussed the SOA Evangelist, the Architects, and the Developers. Today I will discuss the role of the Testers and the characteristics required to contribute to a successful SOA implementation.

One of the most important roles and one that I probably should have included in the Architects post is the Testing Architect. As I have written on CIO.com in my article called Six Questions to Consider Before Building a SOA Testing Team, SOA testing requires a much deeper knowledge of technical skills, including development skills. It might be unrealistic to expect your entire testing team to possess the desired technical skills required to successfully test SOA, but your test architect and your leads should be able to understand concepts like statefullness, distributed computing, and data services, to be able to properly validate the underlying architecture. They also need to be able to take developer test harnesses and update them with their own test scripts.

A successful SOA testing strategy starts with the test architect. This person must have a very in depth knowledge of SOA and should work closely with the EA team. I actually recommend that this person is a member of the EA team, but every business and culture is different. The goal of the test architect should be to set up a framework and a core group of policies and procedures (part of IT Governance) so that the rest of the test team has the tools and the guidance to successfully test SOA. Without an established testing architecture, the company will have to rely heavily on expert knowledge from the entire testing team. I have seen three scenarios through my personal experiences and through my research.

Scenario 1: Underestimating SOA
The first scenario is out right failure caused by not having the tools and knowledge required. This is caused by a company not realizing that their current methodology and internal personnel are not well equipped for testing SOA. These companies do not invest enough in tools, training, and governance and usually can only test the presentation layer and possibly the interfaces. By not understanding the concepts of SOA, they are unable to validate the architecture which leads to poor performing and fragile services.

Scenario 2: Paying through the nose
The second scenario I have seen is relying too heavily on "expert" consulting firms for testing. In this scenario the company bets the farm on an experienced SOA consulting firm and pay rates that far exceed $100/hr. This model cannot be sustained for any length of time unless the company is willing to burn huge amounts of capital (which is not a popular thing to do these days).

Scenario 3: Good balance of internal/external expertise
A more desirable scenario is to train or hire a SOA testing architect, build a solid testing platform tailored for the needs of the organization, and govern the testing process while training the other members of the team. Companies should hire one or more experienced SOA tester, find an experienced consultant or two, or train an experienced and credible internal candidate to take the lead for creating the testing architecture. At the same time the testing experts are charged with transferring knowledge over to the rest of the internal team members. This is critical because a highly experienced SOA tester is in great demand and is a flight risk since they are a rare breed. It is critical to grow the knowledge base internally.

Testing needs
The needs can be broken down into these categories: People, Tools, Governance. So what are the characteristics of a successful SOA tester. The answer is dependent on the architecture that is implemented, which is related to the tools and policies that are put in place. Below is a diagram I often use to discuss the typical layers of an architecture.

From SOA Slides

As I mentioned in the previous discussion about the developers, I see the need and desire to specialize within the layers. The same holds true for testers. Work within the layers happens simultaneously in development. I recommend an iterative development and testing approach which means there should be testers working within the layers simultaneously as well.

Here is what I would strive to put in place, keeping in mind that these are roles and some people may fill multiple roles:

SOA Test Architect
Courageous leader with extensive working knowledge of SOA, distributed computing, integration testing experience, coding/scripting experience, and understands the business. It is likely that you may have to go outside to hire this person or bring in a consultant to assist your top level tester.

SOA testing leads
This person or persons must understand all layers of the architecture (let's not forget security either) and should be able to design test plans that validate both the architecture and the governance model. They should understand how to perform black, white, and gray box tests. Testing abstracted services requires extensive testing in the areas of security, performance, and regression. Throw in the versioning capabilities of services and the fact that service consumers can use services in ways that were not anticipated and the permutations of test cases start skyrocketing. The test leads need to practice risk based testing and balance risks, timelines, and costs. There is just so much more at stake here than in the traditional n-tier architectures.

Business process testers
The business processes should be modeled within some tool and will likely call one or many services. The process flow requires a series of decision points based on variables and constants and can trigger events such as notifications, alerts, other processes, error handling routines, services, and a variety of other possibilities. The testers need to validate the business process as a stand alone entity. For example, if the business process is "validate credit card", the tester needs to ensure that this process handles the inputs correctly, properly runs the validation process, and generates the appropriate output. At this point, the tester need not be concerned with any other processes or services. These testers must work closely with the business and/or business analysts and do not need the breadth of technical knowledge that the leads and architects must have (although it would help). They should be approaching the testing from a business standpoint.

Integration testers
These testers must be much more technical and understand how to work with XML, SOAP, WSDLs, networking & telecommunication concepts, statefullness, and various platforms and technologies (Java vs .Net, Windows vs Unix/Linux vs. mainframe, etc.).

User Interface testers
The company most likely already has an abundance of people who can test the UI. If your company is leveraging mashups, wireless devices, or consumer facing UIs, the complexity of the testing will be greatly increased. These testers may be need to become familiar with AJAX, RIA, portal technology, RSS, and a variety of social software.

Data services testers
These testers must understand concepts of data modeling, database CRUD operations, transformations, security and roles, authentication, and much more. Everything starts with the data and if errors are introduced in this layer, everything else is doomed to fail. You must have a very strong testing lead working in the data services layer since data is the foundation of any successful implementation.

Other areas of focus
The name of the game is speed to market and test automation is a critical component for making that a reality. Performance testing is extremely critical and organizations should practice simulations to try to anticipate future performance of all services. Validating the security model and the governance model should also be part of the overall test strategy. Whoever is responsible for designing the security test plan should read (and fully understand) this book.

Closing comments
I am by no means a testing expert (but I did stay at a Holiday Inn Express last night). I do read a number of testing blogs listed below:

Randy Rice's Software Testing & Quality Blog
Frank Cohen's blog
The ITKO Lisa Soapbox: SOA testing, validation & virtualization
SOA Testing
Mike Kelly's testing blog

Make sure your organization funds the necessary training and tools for testing. From my own personal lessons learned, make sure you invest as much effort in testing and security up front as you do in architecture and development. On my project a few years ago, I wore my developer hat too much in the research phase and did not properly budget for what was necessary for testing. Do not make this same mistake. As hard as it is to sell the business on SOA, it is much harder to go back for more money, especially before any business value is realized!

Upcoming Conversations on the Mad Greek's blog

madgreek65@gmail.com (Mike Kavis) — Mon, 20 Oct 2008 19:43:00 +0000

For those of you who have been reading my blog for the last two years, you might know that after 13 years at my previous job I left the company this summer to pursue multiple opportunities that were available to me. I have been doing some consulting and freelance writing in the mean time but have finally found my new gig. I will be the CTO/Chief Architect for a startup (more details forthcoming in the future) and will have the opportunity to work on some of the newer technology initiatives. So here are some of the future blog topics that I will start covering in 2009 once I get rolling:

SOA - can't seem to let it go! As I wrote in a post at CIO.com, I believe SOA is not just for legacy systems and can be the foundation that startups can leverage as a competitive advantage (see the reasons why)
Cloud Computing - Startups typically have low budgets and leveraging platform (PaaS) and/or Infrastructure as a Service (IaaS) can be a great way to both minimize costs and reduce time to market. As I go through the requirements analysis, risk analysis, vendor analysis, proof of concepts, prototypes, and deal with issues such as stability and privacy, I will share my lessons learned here.
Open Source - We will likely leverage many open source solutions and I will discuss those experiences and decision points here.
Social Software - The company is based in the North East and I live in Florida. It is highly possible that the team I build will be dispersed all over the country and possibly even the world. There will be great lessons learned discussions as well as evaluations of tools to help enable working remotely (virtual whiteboards, live meetings, SaaS solutions for defect tracking, etc.).
Agile - One of our goals is to deliver quickly and at low cost. This involves a lot of the above mentioned topics and will also lead us into the world of Agile Development. I will discuss our challenges and lessons learned in this area as well.
C-Level IT topics - In my new role I will be working side by side with other C-Level people within the company as well as with C-Level people of partner and customer companies. I will have to hit the road and sell and/or promote our products/services and will try to shed some light on some of the interesting topics I come across.
Misc - Other topics that might be worthy of discussing (examples: impacts of financial crisis, VC funding, selling technology to business people and customers, etc.)

In addition, I still do some freelance writing and blogging from time to time. I have a series of discussions coming up on enterprise mashups and will blog about it in the next week or two. I am attending and speaking at the EDM Summit in Orlando next week and will definitely be sharing my presentation on Business Intelligence as a Service as well as covering topics like business rules management, data warehousing, IT governance, and others. I also have two books from Packt Publishing to review:

SOA Governance by Todd Biske
SOA Cookbook by Michael Havey

Once I finish reading these I will post a review on my blog. I am half way through Todd's book so far and really like it.

And finally, I am open to covering any topic that any of my readers would like me to discuss whether it is on this blog, over the phone, or in person. Whenever I travel I send a Tweet on Twitter to let people know where I can be found. I will be in Pittsburgh from Saturday 10/25 through Monday 10/27 if anybody lives there and would like to meet. Don't bug me from 4:15-7:15pm on Sunday because I'll be at Heinz Field pulling for my Giants against a tough Steeler team. The rest of next week I am at the EDM Summit in Orlando.

I look forward to sharing these topics with you all. Over the next two months my focus will be on the business plan and creating a team. We officially launch the company in the December-January time frame. At that point expect to see more discussions on the topics I mentioned above.

SOA Skillsets: Part 3 - The Developers

madgreek65@gmail.com (Mike Kavis) — Thu, 16 Oct 2008 15:49:00 +0000

I have discussed the role of the SOA Evangelist and the importance of the architects. Today I will discuss the different developer roles and the characteristics that make a successful SOA developer.

In a traditional 3-tier architecture it was common that there was a presentation layer, a middle tier or application layer, and a data layer. In some cases, a single developer role was responsible for all three layers. In larger companies, there may have been specialized roles such as a UI developer, an application developer, and a database developer. In an SOA, the concept of an application is no longer relevant except from the standpoint of integrating to existing applications. With SOA, we should be building business services that are application independent. The following chart is one I have used in previous posts which shows a typical breakdown of some of the development roles required for SOA.

From SOA Slides

So let's talk about business services. A business service is the compilation of all of the work done by the collection of developers within each layer. For example, let's discuss a "Shopping Cart" business service like the one we use on Amazon.com. It is most likely made up of services and/or components that live within each of the various layers of the architecture. The presentation layer obviously contains the physical implementation which the user sees and interacts within the browser. The business process layer contains the logical flow of steps that walk the user through the checkout process from start to finish. The business rule layer contains rules about tax codes, discounts, memberships, etc. and the underlying data elements and structures are handled in the data layer. In many instances, companies have multiple data structures that serve similar functions due to mergers, acquisitions, years of legacy systems, 3rd party application purchases, and many other reasons. To abstract these different data structures and present a common data interface that hides the complexity of the physical implementation of the data, the data services layer exists (think master data management).

So to develop this shopping cart business service, all of the people working within the different layers of the architecture must collaborate to deliver the service in a way that it both meets the business requirements and the technical requirements as defined by the SOA Governance model that the company has adopted. Examples of the technical requirements might be...

Adheres to WS-* security standards
Data encryption policies
Platform neutral implementation
Meets specific performance requirements

Why do I bring all of this up? Because developers that will succeed developing in a service-oriented architecture need to have the following characteristics:

Flexible, open to change
Collaborative
Able to work in a setting with peers reviewing their work
Able to see the big picture
Not married to a certain technology
Able to withstand constructive criticism
Innovative

Developers who are protective of their own work or of their technology of choice will likely struggle working on SOA. One of the goals of SOA is to build platform neutral software that is highly flexible, maintainable, and loosely coupled. To build software like this we must shift away from software developing and move to software engineering. In simple terms, we must move from drag and dropping to planning and modeling. We must embrace collaboration, peer reviews, and governance. If your developers don't like these requirements, they either need to change or leave. Otherwise they will be a cancer and will continously feed the forces of resistance.

Ok, off my soap box now. So let's discuss the roles. But before we do let me note that we are talking about roles and not individuals. In smaller companies, a developer may perform multiple roles. In larger companies we may actually see very specialized developers living within a single layer of the architecture. One last disclaimer: I am assuming that an architecture team exists and some form of standards and governance is in place within each layer.

UI developers
If your company can afford to specialize, this is the perfect layer for it. Developers in this layer do not necessarily have to be extremely technical. It is more important that they understand usability, UI standards, and web interface best practices. These people should be comfortable working in prototype mode where they can start with mockups and work closely with the business or business analyst to reiterate through the various visuals until an agreed upon format is approved. These developers must be able to talk to the business in business terms and understand how typical business users interact with web technology.

Business Process developers
There are two distinct roles in this business process layer. One role deals with modeling business processes, the other role deals with integrating business processes with the underlying services and systems. In some companies this role may be served by one person but more likely it will be two because of the difference in the skills required. The business process modeler may not even be an IT person. Some companies have a department that exists within the business that focuses on business process improvement and business process automation. This is the norm for companies that practice Six Sigma or Total Quality Management (TQM).

The business process integrator is a technical role which requires expert experience working with Web services, REST, JMS queues or several other technical areas of expertise. The integrator is the person who connects business processes to the backend technologies which controls the overall flow of the business services and overall composite business application, often coined orchestration.

Business Rules developer
This one is a little fuzzier. Not all architectures have a distinct business rule layer. In some instances, the business rules are controlled in the data layer. For companies who have very dynamic business rules, especially rules that are customer centric and could be updated by end users and even customers, it makes a great deal of sense to abstract the business rules. If a company has a business rule layer and implemented a tool to manage business rules, it is highly likely that you will need technicians who govern this layer much like DBAs govern the database layer. In some case this might be an additional role for a DBA but it does not have to be. Whoever it is they must understand the concepts of abstraction and be looking for ways to empower the end user to react quicker to changes in the business. For example, let's say that a loan approval process requires state specific business rules about what percentage of capital is required from a loan applicant up front before the loan application can be expected. The frequency which this value changes varies by state and must be updated as soon as possible. The best scenario is to take IT out of the process and enable certain users (or systems) with the appropriate authority to update the values as necessary. Whoever is responsible for the business rules must be able to work with the business and/or business analysts to understand the frequency of change, the rights and permissions, and the impacts of the various business rules. There is an amount of overhead associated with creating and managing rules and the person in charge must understand the trade offs.

Data Services developer
Maybe a better name for this person is an information architect. The person in charge of this function is responsible for abstracting the underlying data layer and exposing it the other layers of the architecture and even externally to other systems. For example, let's say that our shopping cart business service allows multiple forms of payment (American Express, Visa, and Pay Pal). In addition, the different products purchased (books, DVDs, clothing, etc.) are managed from different inventory systems. To hide that complexity and to allow us to add additional payment services and inventories with ease, we leverage data services to present the shopping cart service with a logical view of the data. In other words, we create a standard payment and inventory message that the shopping cart communicates with. As long as the shopping cart communicates with these standard messages, the underlying physical implementation of the different payment and inventory services are irrelevant. The shopping cart service simply communicates these messages in the standard format it knows and the translation from the standard message to the physical layout of the receiving systems or services is performed in the data services layer.

From SOA Slides

(This slide is from BEA)

Developers or architects within this layer must have exceptional technical knowledge in the area of data modeling and database design. If the company has a tool to manage this layer (which is highly recommended) then an administrator is also needed.

Database developers
This data layer is typically an area that already exists today within each enterprise. This is where the DBAs live. With SOA, the DBAs must work extremely close with the developers within the other layers of the architecture. They must understand the performance and security requirements of each layer and ensure that the underlying data model meets the needs. Since legacy integration is common in many SOA implementations, DBAs are often called upon to create views or structures or even establish new ETL processes to provide a common view of data to expose to the other layers of the architecture.

Security developers
The security experts may not actually do the development but there must be a person or group of people who understand the new security challenges that SOA introduces. SOA can introduce the following new threats:

Expose components of legacy systems that were never designed to live outside the firewall
Require trusts between multiple internal/external systems without additional sign-ons
Send a single message to multiple partners each with their own distinct security requirements
Expose credit card and other privacy related data out on the web

From SOA Slides

(This slide is borrowed from the following presentation from Mamoon Yunus of Forum Systems)

Todays n-tier security models are not enough when dealing with B2B type SOA implementations. The developers in this area must have a deep understanding of communication protocols, security best practices, web architecture, regulation (ie. HIPAA, SOX, PCI) and WS-* or other standards.

Summary
As you can see there are many distinct developer skill sets required to implement SOA properly. Trying to find a person that can master each layer is not realistic. If you have this person, it is likely that he or she is on your architecture team. The beauty of this architecture is the ability to divide and conquer the problem within each layer. A single business service can be worked on by numerous people within each layer. It requires solid governance, strong collaboration skills, and teamwork to work this way which is why it is critical that the right team of people is assembled to tackle SOA. My next post will discuss the testers and their relationship with the development team.

SOA skillsets: Part 2 - The Architects

madgreek65@gmail.com (Mike Kavis) — Wed, 08 Oct 2008 13:04:00 +0000

In part 1, I discussed the importance of the SOA Evangelist. I also talked about the shift from software development to software engineering. This shift has made the role of the architect critical for the success of any SOA initiative. First, let us talk about the various architect roles required to successfully design an SOA.

Chief Architect - This person, possibly your SOA Evangelist, should have strong technical skills, sound business knowledge, and great leadership skills. Not only should this person understand the ins and outs of SOA, but he/she should be able to explain the value of SOA to the business in business terms, to the CIO in high level technology and business terms, and to the technicians in detailed terms. Depending on the size of the company and the SOA initiative, this person may or may not actively participate in the design. Regardless, this person should be knowledgeable enough to participate in design sessions when called upon. From a leadership perspective, this person is likely the change agent who is the driving force behind establishing and implementing governance, shifting the IT mindset from programming to engineering, establishing the SOA roadmap, and other culture changing elements.

Enterprise Architect - In smaller or midsize companies, the chief architect and the enterprise architect may be one in the same. In bigger companies, there may be more then one EA. The EA has broad domain and business knowledge and works across organizational boundaries to ensure that the architecture meets both the business and IT requirements. Wikipedia says it best when it mentions....

The role of the Enterprise Architect is to take this knowledge and ensure that the business and IT are in alignment. The enterprise architect links the business mission, strategy, and processes of an organization to its IT strategy, and documents this using multiple architectural models or views that show how the current and future needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner.

Domain Architect - The domain architects specialize in specific areas of technology. They are the experts of their domain. Here are a few examples of domains that require specialization:

Application
Information
Security
Infrastructure
Business Processes
Network
Integration

Once again, the size of the company often dictates how many of these roles exist as a stand alone job function or if they are rolled up into a broader architect role. For example, smaller companies may combine application, information, and integration into one role and infrastructure and network into another role. The key for me is that these roles need to be accounted for regardless if its by one or many people. Each role is critical in successfully architecting a true SOA.

Solution Architect - The solutions architect has hands on experience with specific technologies and even business applications. You may have an architect who specializes in Java, .Net, backend systems, web applications, financial systems, ecommerce systems, distributed processing, etc. Once again, I am advocating that the role is addressed and whether or not a company has one or many people with this title depends on its size and budget.

The Architecture Team
As I described above, the team should consist of the following roles (not necessarily individuals):

Chief Architect
Enterprise Architect
Domain Architects
Solutions Architects

The number of people filling these roles vary from company to company. In my previous job, a shop of roughly 200 people, our architecture team consisted of myself as a Chief Architect, an EA, a domain architect, and a solutions architect (even though they all had the simple title of "Architect"). There was an Architect over the infrastructure and network that reported into a different structure and a one person security team. My architect team worked closely with the others but it would have been more effective had we all been on the same team with the same goals and objectives.

I have seen a case study at an enterprise architecture conference a few years back where a global SOA initiative for a fortune 100 company had over 100 architects on the team including numerous EAs and even multiple Chief Architects from different business divisions. There is no one way to slice this pie.

Architect Mindset
You can organize the teams anyway you like but one thing you must have is the proper mindset. The architecture team must be focused first on the business drivers that the SOA initiative has set out to solve. If the team loses sight of these drivers then SOA will become an IT project instead of an important initiative for the entire corporation. You must have the business buy-in throughout the project to reap the true benefits of SOA. Please read 8 Winning Characteristics of Successful SOA Implementations which I wrote for CIO.com that summarizes the critical success factors that wer common among the winners of the SOA Consortium/CIO.com SOA Case Study contest earlier this month.

Second, the team needs to ensure that they are not an Ivory Tower architecture team. SOA is too important for architects to be preaching philosophy from the top of their perches. The architect team must be the change agents required to move the organization away from the traditional silo driven application development approach and into a more collaborative engineering approach that focuses on the long term vision not the short term and short sighted approach that many companies practice today.

Third, this team must have an open mind. They need to evaluate current business processes, current IT practices, and current systems, and provide the necessary change and direction required to move the organization forward towards the vision established by the business and IT and reflected in the SOA roadmap. Without changing the way IT approaches development, it is likely that the team won't be able to differentiate between SOA and web services. Education and evangelism is key to understanding the proper way to architect and govern your SOA.

In part three I will discuss the developer role. In part four I will discuss the testers.

SOA skillsets: Part 1 - SOA Evangelist

madgreek65@gmail.com (Mike Kavis) — Tue, 30 Sep 2008 13:22:00 +0000

There is no shortage of advice on the web of the do's and don'ts for tackling SOA. One topic that I don't see discussed much is the assessment of a company's IT skills as it pertains to the ability of a company to comprehend and actually deliver on the promise of SOA. This is part one of a series that addresses the many skillsets required to deliver a Service-Oriented Architecture.

I have mentioned in the past that companies that have not invested in enterprise architecture may struggle as they shift from software development to software engineering.

Here are the wikipedia definitions of these two terms:

Software development is the translation of a user need or marketing goal into a software product

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

There is a major difference between the two. Software development is the creation of software regardless of the means used to accomplish the task. Software engineering involves using a defined set of processes, procedures, and standards with the goal of improving the reliability and maintainability of the systems being built. So for companies that don't take a software engineering approach to software development, they may have huge challenges doing SOA with their existing staff. Throughout this series I will make reference to the shift from development to engineering as a key aspect of each skills assessment as I discuss SOA evangelists, architects, developers, testers, and many others.

When kicking off an SOA initiative, companies should perform a readiness assessment to identify areas of concern and create action plans to address them. For this series of posts, I will focus on internal skills in the IT organization.

First and foremost, a SOA Evangelist is critical to the success of any SOA initiative. This person must understand SOA inside and out from the perspective of both IT and the business. From the business standpoint the evangelist must understand the business drivers, the financial impacts and ROI, and can speak to the business in their language. From the technology standpoint, the envangelist must understand all aspects of the archtiecture in order to communicate effectively to developers, testers, security professionals, architects, network and infrastructure personnel, project managers, business and process analysts, and management. The evangelist should promote SOA and importance of governance and should help establish the Center of Excellence (CoE) needed to provide oversight and enforce the principles of software engineering. I have seen and read about several instances where SOA initiatives that were successful quickly turned to chaos upon the departure of the company's evangelist. In one case, the company quickly lost sight of the business drivers and began to debate on technical issues like whether the services should be done in .Net or Java. These are the unfortunate consequences that happen when SOA is left to those who don't have a full understanding of the technical and business benefits of SOA and focus on software development as opposed to software engineering.

Characteristics of an SOA Evangelist
An SOA Evangelist should have strong leadership skills, strong technical or even architecture level skills, should be business savvy, have a grasp on core financial concepts, and be comfortable presenting to people at all levels. On the same day, the evangelist can be expected to discuss key issues with C-level executives and then roll up the sleeves and explain the advantages of the distributed nature of SOA to the technicians. This person can expect to be confronted with various pockets of resistance which is natural for initiatives that introduce new concepts to an organization. Organization change management skills are a necessity for a person in this position. One of the key challenges for a person in this position is to get the staff engaged and give them a sense of ownership. Without this, the staff may look at the the initiative as a pet project of the evangelist instead of what it is, a key initiative for the business. The evangelist will have to lean on the exectuive sponsor and top level management to help with this.

Life without a SOA Evangelist
I feel that without an SOA Evangelist, companies will struggle for a number of reasons. First, having an expert on SOA who spreads the knowledge throughout the organization is much more efficient than having various individuals coming up with their own definitions and perceptions of SOA. An evangelist can brand and market the vision of SOA for the entire company so everyone is talking the same language. Second, the evangelist also bridges the gap between the business and IT and ensures that the technologies being implemented are focused on the business needs and not the needs of IT first. In addition, the evangelist can translate IT speak to business speak and spare the business of technical details that tend to dominate conversations when technicians discuss SOA. But most importantly, there is usually many different silos within both the business and IT that must be brought together to work as one. The evangelist is likely the person who knows enough about each silo (at a high level) to help bring all of these parties together. Without cohesion between the silos the SOA initiative can spiral into chaos.

In my next post I will discuss SOA and the architects.