Enterprise Initiatives

This blog focuses on Enterprise IT topics such as Enterprise Architecture, Portfolio Management, Change Management, Business Process Management, and recaps various technology events and news.


Showing posts with label ESB. Show all posts

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)






One of the most critical tasks that the champion of your SOA initiative must perform is to quantify the total cost of ownership (TCO) of the SOA initiative. Some executives might think that once they buy the ESB they are done. This is far from the truth. Here is a list of items you should plan for up front and create a road map for how much and when each of these items need to be procured:

  • The Stack (BPMS, ESB, Data Services, Portal, etc.)
  • Testing tools
  • Training, training, and more training
  • Professional services from the Stack vendor(s)
  • Professional services from the implementation partners
  • Conferences, site visits, partner meetings, and other learning opportunities
  • Acquiring personnel with new skill sets
  • Organizational changes
  • Annual maintenance costs
  • Network infrastructure (if necessary)
  • Additional security hw/sw (if necessary)
  • Funding a project and tools to implement SOA Governance
I am sure I missed several others. The key here is that to successfully implement SOA, your company must make a long term financial commitment to architecture that never ends. Investing in SOA goes far beyond buying the Stack.

The Stack
Depending on your project's objectives, you may need to purchase a variety of products that make up the Stack. In my case, we already had an enterprise portal. We purchased an ESB, a BPMS solution, and a data services tool. With each tool you need hardware, racks, floorspace, etc.

Testing Tools
Unless you already have a robust testing tool for testing enterprise architectures including web services or JMS messages, you probably need additional tools. We have many modules in the Mercury suite, but nothing for performing testing in a service oriented architecture.

Training
Do not underestimate this one. Not only do you need to train administrators for every piece of the stack and for every additional tool you purchase, you need to train a large number of IT staffers about SOA, Governance, and developing and deploying with the new products. There are five different courses offered just for the BPMS tool we bought. One is for administration, two are for programming, and two are for modeling. Training is also a continuous process and not an event that occurs by sending a few people off site for three days.

Professional Services (Stack vendor)
Take my advice on this one. Use the vendor's professional services to install the products. Do not, I repeat, do not try this on your own or with consultants. The beauty of SOA is how it easily integrates across different technologies. My lessons learned is that this is true once you suffer through the upfront configuration nightmares required to create the initial environments. If anyone other then the vendor sets up the environment, you may not get the support you need from the vendor to fix it. Use the vendor to implement the products and have them come back when you have built something and have them certify the environment with your code running on it. Tweak the system now before you go live!

Professional Services (Partners)
Unless you are fortunate enough to have the necessary skill sets within your current staff, I highly recommend finding a partner with years of experience implementing SOA. Choose your partner wisely and embed your staff with them for knowledge transfer.

Learning opportunities
Don't underestimate continuous learning opportunities. I still attend conferences, webinars, lunch and learns, and various other opportunities to talk to people and learn from their experiences. Get out of the office and see what the rest of the world is doing. Learn from their mistakes and their success stories. Don't forget to budget for travel.

New skill sets
Our SOA/BPM initiative introduced a number of new skill sets. You may need to hire incremental headcount or replace existing roles with new roles. SOA talent is in high demand and is not cheap. Don't forget recruiting costs, relocation expenses, and the overhead of onboarding.

Organizational changes
You may find that your current organizational structure is not optimal in the new world of SOA. Reorganizations sometimes have costs associated with relocations, promotions, merit raises, administrative costs, new reward and incentive programs, etc.

Annual Maintenance
Expect to pay between 18-21% in maintenance costs for everything you buy.

Network infrastructure
Your current network infrastructure may not support the requirements of your SOA initiative. More sophisticated load balancers, additional monitoring tools and agents, and hardware accelerators are just a few things you may need to consider.

Security
If you are exposing business services externally to customers and partners, your security requirements are more critical then ever before. There may be additional purchases required for authentication, auditing, logging, encryption, ID management, etc.

SOA Governance
This might be the most underestimated piece of the entire SOA financial model. Implementing SOA Governance is a project within itself. It requires dedicated staff, training, and tools for enforcement. Don't cut expenses here. Invest in governance because the success of your SOA implementation for years to come is heavily dependent on your ability to enforce policies and best practices. Buy a repository. Don't try to manage this manually or you will drown.


To sum it up, SOA is not a tool you buy. SOA is a new way to develop software and touches every aspect of your enterprise. Invest in SOA or the money you spent on your stack will never reap the benefits that SOA can offer.




Virtualization is another hot topic in IT today. It allows you to run multiple virtual or logical representations of physical machines, side by side on the same physical server. Many companies are putting strategies in place to consolidate servers and to reduce the cost of hardware, maintenance, power, and floor space. At my work we have a cluster of physical machines using VMWare that have allowed us to run 115 virtual servers on it. There is room for more and we will continue to move to that platform. Virtualization makes a lot of sense in the eyes of the system administrator.

So why is a software guy like me so excited about it? To me, it is much more then a way to control costs. It also allows us to be more agile, to react to capacity issues faster, deploy easier, and create faster applications. Allow me to expand on each one of these points. The following statements assume that you have a cluster of boxes with available capacity to add additional virtual machines.

Agile - How long does the procurement process take in your company? I have seen companies' server procurement cycles take from two weeks to six months. The norm in my world is about a month. A virtual machine can be created in 15-20 minutes without having to purchase anything.

React to capacity issues - On Friday at 10pm, your web site generates a ton of unexpected traffic which causes your servers to exceed their capacity and fail. Your systems administrator logs on from home and quickly adds five more virtual machines using a snapshot of an existing production virtual machine. In under an hour he has the system back up and running.

Deploy easier - Your application can be configured as a virtual appliance. This allows you to create a virtual machine that consists of the operating system and application software for all the tiers of your application and bundle it as a single file. Microsoft is leveraging this approach as a way to allow people to try out the latest version of Outlook without having to install hardware and software. Think about being able to deploy your multiple tier environment as a single file. Take that snap shot and deploy it at your DR site and you have knocked a huge chunk of time off your implementation phase.

Create faster applications - This is the topic that gave me the urge to write this post. Think about this architectural strategy for your web sites. Put all of your web servers, application servers, and database servers on virtual machines and create your virtual appliance. Since all of these virtual machines are on the same physical server, you could actually leverage the PCI bus instead of the Gigabit Ethernet. The PCI Bus is over 400 times faster then Gigabit Ethernet which should give you incredible response times for your application. What's even cooler, is that you can have your virtual web servers "sitting" outside the firewall in the DMZ while your application servers and database server is "sitting" inside the firewall. You read that right! Even though these virtual machines are physically installed on the same server, you can configure them to logically be located in different areas.

Think of all the possibilities. We all know the power of distributed systems. Distributed systems allow you to perform parallel processing across multiple nodes to achieve more work in shorter intervals. The downside of distributed systems is the cost of the physical servers and the management of software across the nodes. Enter virtualization. You can install several virtual machines at minimal cost and easily manage the software by updating one virtual machine and taking a snapshot. Then apply the snapshot to the other virtual machines.

To take that concept one step further, you can leverage this distributed model to create multiple virtual machines to act as an application server farm. If you are implementing an SOA and have an ESB in place, you can configure the ESB to load balance your services across these virtual machines to maximize your throughput.

The possibilities are endless. The point is that virtualization is more then just a great solution for consolidation and server management. Virtualization should be included as part of your application architecture strategy.



A colleague of mine uses a great analogy to explain the purpose of an ESB (Enterprise Service Bus). He starts by reminding us of how PCs work. The PCI Local Bus within the PC is a high speed channel for providing a centralized mechanism for connecting multiple hardware components within a PC. Without the bus, the inside of your PC would look like a spider web of wires with each component having to connect to all other components. The following diagram shows a simplified view of a PCI local bus.


The ESB performs a similar function within a service oriented architecture (SOA). When architected correctly, the ESB becomes the centralized mechanism for controlling all messages and events that occur between the various layers of the architecture. The ESB centralizes security, routing, transformation, invocation, and service management. Look at the diagram below and see how it looks similar to the PCI local bus.


I have seen a lot more head nodding and a lot less glass eyes when using this analogy to explain the role of the ESB. Give it a try.

Subscribe to: Posts (Atom)

My favorite sayings

"If you don't know where you're going, any road will get you there"

"Before you build a better mouse trap, make sure you have some mice"