Enterprise Initiatives

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:

• Agile SOA: Empower the Business with Business Rules Engines
  
• Agile SOA: The Flexibility of Business Processes
  
• Agile SOA: Leveraging Data Services
  
• Enterprise Mashups: The Icing on your 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:

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!

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.

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!

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.

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:

1. Strong leadership with the ability to promote and manage change
2. A well run and planned Enterprise Architecture
3. Solid working relationships and trust with the business partners
4. Discipline
5. Fiscal awareness
6. 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.




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.


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.).


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:

1. Business Process Outsourcing (BPO) - (example: Payroll, HR, web site hosting, etc.)
2. Acquire new skills (SOA implementers, BPM experts, Cloud specialists, etc.)
3. Strategic partners (Organizational Change Management expert, EA help, etc.)
4. Technology outsourcing (IaaS, PaaS, SaaS, etc.)
5. 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"

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.

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:

1. Flash enabled output
2. Subscription services
3. Mobile capabilities
4. Alerts
5. Great scalability
6. Logging
7. 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.

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!

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.

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.

I frequently discuss SOA with potential clients, fellow architects, and business partners. Each audience requires a discussion that is tailored to the appropriate level of technical and business expertise. Today I had to present to a CEO and a few of his top staffers about what it takes to launch into a SOA initiative. So I put together a presentation similar to the one below and felt like sharing it with all of you.

Before you look at it let me put the discussion into context. The target audience is hi level management, business and IT, who are already bought into SOA and are trying to understand what is involved before they launch into a full blown SOA initiative. This is not a presentation for architects, rather it is to inform C-Level stakeholders what is required from a business, technology, and culture standpoint.

I also had to sell to them that I know what I am talking about, hence the first few slides about my background. One last note: Some of the slides are mostly visual and only get the point across when backed up with talking points.

I hope this adds value to some of you. Enjoy!

There has been a lot of excitement around Web 2.0 technology lately. It appears that we haven't learned much from our Web 1.0 days, also known as the .Com days. These exciting new technologies allow for companies to quickly produce new web sites and easily extend existing web sites. The problem is people forget that to be successful in the long term, you still need a reliable and well designed architecture and you still need some form of governance to ensure that the end product can meet high levels of quality of service.

What do I mean by Quality of Service (QoS)?
In terms of web sites and software, when I talk about QoS I am referring to:

• Uptime
• Performance
• Service Level Agreements (SLAs)
• Minimal defects
• Scalability
  

Nowadays, a web startup can quickly produce a service on the Internet at low cost. They can simply take advantage of the LAMP stack (Linux, Apache, MySql, PhP), leverage existing Mashups, and build robust user interfaces (RIAs) to produce a cool, eye candy web site that consumers can access for free. Unfortunately, quick is becoming quick-n-dirty.

Balancing Agility with QoS
Startups are faced with a dilemma. They typically have a limited amount of time, money, and resources. They need to get a prototype up and running quickly to give them an opportunity to go after VC funds. The defining moment comes when they get the funding and then have a limited amount of time to produce a Beta version soon to be followed by a real production version. This is where many startups miss the boat. Many prioritize speed to market over sound architecture design. It is a tough decision to make.

• Do I spend a lot of time and money now and risk missing the window of opportunity?
  
• Can I worry about scalability after I see how well received the web site is?
• Can I afford to pay an experienced architect now or can I wait until we have more money and a good stream of traffic?

Many startups can get away with postponing some of the critical design aspects and target a later release of software to address QoS. But others have not been so successful. Right now, everyone is fully aware of Twitter's Fail Whale, a symbol of incompetence and a colossal architectural blunder.

From Web site crashes

Twitter had quickly become a rising star on the web with millions of users. In the April time frame their traffic spiked to a level beyond what their underlying architecture could handle. Now Twitter is the joke of the town and are victims of daily outages and performance issues. What we found out is that behind the scenes the baby is ugly. Twitter recently responded to some questions from Techcrunch and revealed more information about their "architecture" then any sane person would offer. Here is a summary of what I learned:

• Use one database for writes (because "replication of MySQL is no easy task")
• Limited scalability -3 physical database machines "POWERING ALL OF TWITTER"
• Human Intervention required - "There's a lot of necessary handholding and tweaking "
  
• They plan to grow operations, rather then fix the handholding
• Tightly coupled - massive traffic on one part affects all
• Many design flaws - "Everything from faulty process, environment, configuration, and just plain load"

Their solution is to hire top talent at top prices and go into fire fighting mode to save this product. This is the typical result when a company with a successful product takes short cuts in terms of architecture and design. You can pay for it now or pay double later. Twitter is paying big now in salary, lost customers, and declining brand value. This is a worst case scenario for a company who generates zero revenue and who's goal is to be purchased by a big spender.

But Twitter is not the only startup having issues. It is becoming common for me to experience crashes and outages in my daily routine of using various new web sites and services. There have been days that I have seen four sites down at the same time. It is getting so common that I started creating a collection of screen shots.




Technorati has been struggling recently with a surge in web traffic. Countless other startups have flashed their cute crash messages on my screen. To me, the joke is on them. It's no wonder that the corporate architects of the world (me included) get a little annoyed when the media and talking heads start touting Web 2.0 and Mashups as the silver bullet for enterprises. Many have said that we should skip SOA because it is hard and time consuming and instead go the WOA route. I think Web 2.0, Mashups, and WOA are all great technologies, but when they are applied to an architecture that does not scale or do not follow some form of governance to assure some level of QoS, then you will likely need to design a cute outage web page to entertain your users as your team scrambles to bring the system back on line.

Here is one that I have created for any new startup out there.

In the .Com days companies were built overnight and threw together web based systems without a lot of thought about architecture and planning. Many of them crashed and burned and left investors with empty pockets and sent day traders back to their full time jobs. Now we are in the Web 2.0 days and I see this pattern developing again. New websites are popping up everyday as the social networking craze races across the globe. Don't get me wrong, I am a huge fan of Web 2.0, especially the social networking aspects of it. But just like in the .Com days, there is a huge race to be the dominant web site like Twitter who attracts millions of users with the hopes of being bought by Google or Microsoft. Once again, architecture seems to be an afterthought. Twitter, who has being growing at a rapid pace, went from the web darling to the site that is always down in the course of a few short weeks. But this is a pattern that is not unique to Twitter. I have saved a few screenshots of cute little error messages that I frequently get when I use all of these hyped up web sites.





I wish these companies would spend as much time on capacity planning and architecture as they do coming up with "funny" error messages. They are only funny to me when they are rare. I have seen the whale way too many times and if the"Monster gets lost" one more time I won't be back.

When it comes to stability and reliability, there are no shortcuts. If you are not careful you might wind up like Twitter. Last month they looked like a multi million dollar website that was changing the world and on the verge of making its founders millionaires. Now they are struggling to keep their customers as their system fails to keep up with the demand. This has opened the door for some other startups like Friendfeed. Hopefully they invested in architecture so they don't run into the same issues when the masses flee Twitter and open up accounts on Friendfeed.

The moral of this story is that architecture is critical for sustaining success for any software product. You can pay now and build it right up front, or you can pay later and call in the firefighters and the PR folks.

I have worked on many large enterprise initiatives over the years. Some were successful and some were not. As an avid researcher of my trade, I have also read about many failures of large initiatives. Being the lessons-learned kind of guy that I am, I always try to understand what worked and what didn't so I can make sure that the next enterprise initiative can avoid failure. Whether you are implementing SOA, Enterprise Architecture, forming a PMO, introducing a new programming language, or merging with another company, I have seen a consistent pattern of failure that can be summed in the following 10 categories:

1. Poor Communication
Enterprise projects usually impact a large amount of people. This requires constant communications to all levels of people throughout the organization. A strong communication strategy can help with this. Use a combination of town hall meetings, portals, blogs, group meetings, emails, wikis, bulletin boards, posters, and any mechanism you can think of to get the word out. In larger companies, this can be a full time job for somebody.

2. Underestimating or ignoring impact of change
This is another way of saying poor change management. People need to know WIIFM (what's in it for me). Resistance to change can kill any project. Your initiative must have a champion who carries a lot of clout. The leadership, lead technicians, project managers, and all of the visible people in these projects must be positive forces and constantly promote the vision and the future state. I wrote a post called BPM, SOA, and the Swing Voters that discussed how important it is to stay focused and positive and not to show frustration. People will feed on the attitudes of those leading the initiatives. You must address resistance head on and address people's needs to help them turn the corner. For those who just refuse to buy in and become roadblocks, show them the door!

3. Lack of Leadership
IT Leadership requires excellence in three key areas: Technology, Business, and People. If the leadership is missing any of the three components you are doomed. I have seen some projects succeed where the leader was not technical but relied on strong technical people below them. I have never seen a large enterprise initiative succeed when the leader did not have people skills. Not having the business knowledge often kills projects because the projects tend to be done for the sake of technology and not for business reasons. In this case you can deliver the most impressive solution in the world, but the business might reject it because their needs were not taken into consideration. The leader must work just as hard if not harder then the people on the team. I have witnessed one "leader" assign his team a ton of work over the weekend and then left at 5pm on Friday and said "See you Monday". That created an all out revolt. The leader must have integrity or nobody will follow.

4. Lack of strong executive sponsorship
For these projects to succeed you must have somebody high up in the organization with a lot of clout. There will be many obstacles to overcome and key decisions to make. You need somebody strong to help make and enforce those decisions and remove major hurdles so the team can get the work done. This is a critical part of change management.

5. Poor project management
Scope creep is a project killer. Managing scope and requirements are the key to any project. Often, large enterprise initiatives have a ton of logistics that need to be identified and managed accordingly. These initiatives also tend to span multiple teams across various departments. The project manager must coordinate all this and effectively communicate to people at all levels. And don't forget risk management!

6. Poor Planning
This could also fall into a category of unrealistic expectations. Initiatives like SOA require a well thought out strategy. Many IT shops do not have the patience for this and rush into their project head first without a clue of how to actually accomplish their goals. When it fails they claim that SOA doesn't work. If you are going to take on a big culture changing technical project take the time up front to do the necessary research and create a roadmap. Then put a plan together to get you from initiation to implementation.

7. Trying to do it cheap
Another common mistake. Organizations want it all, but they don't want to invest the time and money. I have seen many projects get completed using this strategy, but they almost always run over budget, are late, are missing many features, and have many various quality or process issues due to the quick-n-dirty approach. Remember, the dirty stays around long after the quick is gone. Doing things cheap often costs more in the long run. I have witnessed many projects that didn't fund the appropriate number and types of resources. You wind up not creating documentation, not having the bandwidth to sufficiently test all of the use cases, not having time to architect it right, and you burn people out in the process. Another issue is that underfunded projects usually don't provide the team with the necessary tools to do the job and do not prepare the organization for life after rollout. Even worse, you may wind up picking the wrong vendor, whether it is software or professional services. Picking the wrong vendor can be disastrous.

8. Lack of technical knowledge
I'll use Enterprise Architecture as an example here. If the person leading an EA initiative does not have a solid understanding of architecture, application development, security, infrastructure, process, and the business, you might as well not even start this initiative. You can have all of the leadership and communication skills in the world but if you lack the technical know how you are doomed. Many enterprise initiatives are very expensive undertakings. Don't pick a leader with the "I stayed at the Holiday Inn Express" mentality. You wouldn't ask me to remove your appendix so why would you have somebody with little or no knowledge of the technology at hand lead your enterprise initiative.

9. Lack of sound business case
You can get all of the other issues right but if your solution has no business context then you are wasting your time. I have seen this happen with many SOA projects. IT teams with great intentions go off into their ivory towers for months or years and come out with tons of great documents (usually outdated) and a nice service oriented architecture. Then they try to convince the business to use it. Good luck. Justify these initiatives with business drivers. I have beaten this horse to death on this blog (here, here, and here).

10. Poor vendor management
I have seen this happen far too many times. Somebody hires a high priced group of consultants and let's them run wild. Consultants goals are similar to your goals but that is not a good thing. Both the consultants and your goals are to make as much money as possible for the company. The difference is you are trying to maximize profits for your company and they are trying to maximize profits for their company. If you don't manage them closely they will succeed at their goal and you will fail at yours. Also, the consultants will not have to stick around to support what they build, but your team will. You should make sure that what they build meets your requirements, your standards, your needs, and your timelines.

Summary
I have a saying from my 20+ years of working on IT projects. It goes like this.

"I have worked on so many projects that I know all of the things NOT to do."

That's the easy part. Knowing what to do is much harder. I'll leave you with this post called EA, SOA, and Change which has a very successful formula for enterprise initiatives.

1. Build strong business case
   
2. Secure executive sponsor and top level buy in
   
3. Create a Road Map
   
4. Communicate the Road Map
   
5. Empower Others to Act on the Road Map
   
6. Start small, deliver early and often (agile)
   
7. Expand, add incremental value
   
8. Govern

There has been so much hype about SOA and now WOA that sometimes I think we focus more on fantasy then reality. Yes, both of these technologies offer huge potential benefits but they are both just another tool in the toolbox. Neither one of these will solve world hunger as some media types tend to think.

The WOA craze seemed to start shortly after Anne Manes pointed out that many of the companies she talked to were failing in their SOA efforts. Then came the quick fix, WOA. Many pointed out how the business can grasp the concepts of WOA and not SOA. Others pointed out that it is easier and quicker to implement then SOA, which they claim takes years to implement. I believe WOA is a great compliment to SOA, but I fear many people are thinking about WOA instead of SOA.

Implementing SOA takes vision, leadership, planning, and architecture, something that many IT shops don't have the patience for. Instead they opt for quick and dirty habits that lead to the inflexible, costly to maintain systems that so many of us are stuck with today. I fear that if we bypass SOA instead of complement it with WOA, then we are are going to wind up with "Quick-n-Dirty 2.0", a web enabled mess. There are no shortcuts to developing a sustainable, flexible, and maintainable architecture. We should use these technologies where they make sense. They are not the end-all, do-all answers to our problems. The excitement that I hear about WOA reminds me of the day trading craze of the late 90's. Everybody was looking to get rich quick. We need to make sure that we don't get too crazy with WOA and quickly build nice eye candy systems that we can't maintain, have no control over system performance and SLAs, and can't fix when they are down.

I know this sounds like doom and gloom. I am actually a fan of WOA. But I am concerned that many companies will dive in head first without much thought about architecture, infrastructure, support, change control, dependencies, and many of the other critical areas that a sound enterprise must consider when it introduces new applications into the production environment.

Remember, we are architects not day traders.