Rational Automation Framework Adds Support for New Runtimes

I am very pleased to inform you about the IBM Announcement yesterday which extends the ability of  Rational Automation Framework to support managing configurations and application deployments for other IBM and non-IBM middleware environments.   In this announcement letter, IBM announced the MidVision extensions to IBM® Rational® Automation Framework for IBM WebSphere®.    IBM Rational Automation Framework  (RAF) already supported WebSphere Application Server and Feature Packs,  WebSphere Process Server, WebSphere Registry and Repository, WebSphere Portal Server,  WebSphere HTTP Server for install, patching, configuration and application deployment.

For those of you who aren’t familiar with RAF,  it is a customizable and extensible framework for management and control of complex middleware environments. It provides a tool for middleware environments that can deliver automation and consolidation capabilities for administration of development, Q&A, staging, and production. The framework helps businesses increase productivity, improve speed, quality, and consistency of application delivery, and reduce costs of standards compliance, IT governance, and disaster recovery.

With MidVision Extension to IBM Rational Automation Framework for WebSphere Connectivity, IBM now extends IBM Rational Automation Framework for WebSphere to offer core automation benefits to two key middleware environments from the WebSphere Connectivity portfolio:

  • WebSphere MQ Series
  • WebSphere Message Broker

In addition, IBM Rational Automation Framework for WebSphere for the first time offers support to non-IBM middleware platforms with two additional MidVision extensions:

  • Oracle WebLogic Application Server
  • RedHat JBoss Application Server

RAF leverages the Build Forge Automation technology.   Those of you that are at Impact should stop by the Deployment, Planning and Automation Pedestal to check the new product out.

IBM Deployment Planning and Automation

Deployment, Planning and Automation is a new solution area that the Rational Software Delivery Automation products are playing an important role in.   The idea is that solution architects today must collaborate with a variety of teams to plan solutions and their deployment.  These include members of the development team,  release engineers and middleware administrators.  Often this collaboration is done using Power Point slides or Visio diagrams that are simply pictures that very quickly become out dated.   In my first Web Cast for this business segment area,  Vinit Kutty and I describe the challenges with collaborating using this common approach and propose a new  approach described in the IBM Deployment Planning and Automation Solution.    I encourage you to watch the Webcast and share your feedback here with me.    The products included in the solution are Rational Automation Framework,  Rational Asset Manager (Of course!!) and Rational Software Architect.  Enjoy!

Carlos

New Guy!

Hello All,  I am the new Segment Leader for Rational Software Delivery Automation.  Some of you may remember me from my previous role as the product manager for Rational Asset Manager.   RAM was the product I previously brought to market and managed the growth of for 3 years.   I am excited to lead this new business segment that includes the Rational Build Forge and  Rational Automation Framework for WebSphere.  We hope to see the family of products in the segment grow shortly.   I am looking forward to publishing new posts with other members of the SDA team.    Here are some of the areas I plan on writing about:

  • Tips & tutorials on how to better use SDA tools
  • How we use SDA tools to build our solutions
  • News and announcements relevant to SDA
  • Our thoughts on future SDA directions and how you can influence them

Sharing this information and collaborating with you will be hopefully be helpful for your teams as you work on your projects.   It will also help us, as we learn from you and the comments you leave.  Our ultimate goal is provide you more effective software delivery solutions that help you achieve your business results.

Thanks and look forward to working with all of you.

Carlos Ferreira

Article about Automated Test Infrastructure

A team recently published a great article on IBM’s developerWorks site that illustrates a test automation architecture ecosystem.  This is a great example of a DevOps mindset and shows how connecting development and operations approaches and tools using automation leads to a more productive and efficient environment for a specific discipline; in this case, Test.

This article on the IBM website is:  here

Twitter as Simplifier

I can’t say that I am a Twitter addict.  It has its uses and benefits, for sure, but I tend to be more pragmatic about what I use it for rather than over-enthusiastic.  One of the great things about it though, is the enforced brevity of its format.  That leads to amusing and brilliant gems such as one Tweet that I found here describing DevOps as applied to a number of issues:  ”elegant versions of the crap you hacked in perl 10y ago”

Rather says it all in far less than 140 characters.

Automation Value Estimators

Figuring out the value of automation can be tricky.   IBM Rational recently put a couple of helpful tools up on the website to help with this.  These value estimators are a simplified synthesis of the expertise gained by IBM consultants in the field.  While there is, perhaps, no substitute for a company-specific or environment-specific analysis, these are great examples that will help someone get a general idea of how to get value in this area and should provide a starting point from which to move forward.

The value estimators are here.  (Note:  There is a login screen, but it can be bypassed.)

Why Automate?

As the DevOps discussion gains momentum worldwide, it is beneficial to actually stop and look at the reasons to automate things on a more general basis.  We should do this not so much because it is some great mystery of the universe, but because it is valuable to have a structure within which to discuss the topic.  Given the results-oriented culture associated with DevOps, it is especially helpful as a way to focus effort, avoid over-optimization, and generally prioritize where and how to apply automation.

In most general terms, there are five main benefits to applying automation.  They are, in no particular order:

  • Speed
  • Traceability
  • Repeatability
  • Predictability
  • Infrastructure Reuse

The reason that these are in ‘no particular order’ is that the priority associated with them will be governed by the overall business – across discipline areas.  One discipline area might have a specific need for one or more of these, but at the business level, there might be a much more costly cross-disciplinary item that will take priority.  That can be hard for folks without visibility to understand, but businesses must be brutal in these assessments and focus first on the biggest return – not the most popular or visible.  That is the nature of efficiency, prosperity, and ultimately, survival in a competitive world.

Going forward, we’ll take a look at each of these five main benefit areas, how to begin tapping and prioritizing actions to gain the benefits, as well as some of the pitfalls associated with them.

Top 5 Reasons to attend the Software Delivery Automation track at Innovate 2010 (June 6-10, Orlando, FL)

Top 5 Reasons to Attend the Software Delivery Automation Track at Innovate 2010

1. Customers will meet their peers offering real ideas for better leveraging Build Forge and the Rational Automation Framework for WebSphere.

2. Attendees will get an in-depth look at how automation is the key to improving application deployment, productivity, repeatability, and reliability – as presented by our customers and by IBM experts.

3. Attendees will learn how IBM Rational Software Delivery Automation solutions can help automate processes and dramatically improve the efficiency & cost structure of their organization.

4. Sessions provide the training and best practices that deliver the real benefits from this solution. For example, learn how the Rational Automation Framework for WebSphere can help you manage WebSphere configurations and automate application deployments.

5. Attendees will learn how Agile and Cloud factor into the Software Delivery Automation solutions.

This track is for IT managers, practitioners, administrators, WebSphere administrators, and advanced users who want to learn how IBM Rational Software Delivery Automation solutions can help automate their processes and dramatically improve the efficiency & cost structure of their organization. In order to optimize software delivery, organizations need to focus on automating, managing, standardizing, and tracking processes throughout the delivery lifecycle. Attendees will discover how automation is the key to improving application deployment, productivity, repeatability, and reliability.

Enter promo code “SDAT” when you register to receive $100 off your registration.  http://www-01.ibm.com/software/rational/innovate/register.html

 

 

Chain Chain Chain – A Chain of Tools

There has been a lot of talk recently about “toolchains”. Simply put, a toolchain is a set of tools used, typically in a serial manner, to accomplish a task. This concept is often associated with factories moving workpieces through assembly lines. In order to produce a finished good, the pieces have to move from tooling station to tooling station and have work processes applied to them. The sequence of tooling stations became the “toolchain”.

The concept is very applicable to the software delivery process, but it shows up most often in a very narrowly defined ‘compile, link, run’ activity. However, companies are becoming increasingly aware that the delivery process is much more complex than it used to be. Each discipline has its own toolchain while working on their aspect of the delivery lifecycle. In fact, the traditional focus on specific disciplines such as development, or operations, without taking the whole into account, has led us to actually need to have a discussion about bridging the DevOps gaps in the first place!

As a software delivery organization grows and matures, toolchain management becomes a task unto itself. There are many reasons for this: ‘standard’ tools change and evolve, new lines of businesses are spawned, companies merge or acquire each other, etc. Whatever the dominant causes for a given organization, the result is the continued proliferation of toolchains. A director at the telecommunications provider quipped, “Yeah – at this point, we probably have 35 to 40 ‘standard’ tools for just about every task”.

This is not intended as a hand-wringing plea for standards and limiting tools. That is certainly a noble goal, but history has shown that it just does not happen. And the drivers that lead to tool proliferation are not all in the control of the software delivery organization in the first place. Some may not even meet the definition of “controllable”. The goal of this post is to define this as one of the core factors that must be managed as part of efficiently managing the DevOps activities in a software delivery organization. Future posts will discuss pragmatic solutions and practices that help manage this aspect of DevOps.

Dogs and Cats Living Together

There are certain groups in the world that you just don’t expect to coexist. No, this is not a political blog, so we will not be talking about any of the world’s trouble spots. There are, after all, plenty of “dogs and cats” situations in just the narrow sliver of the world that is the technology marketplace. In fact, the “poster children” for this phenomenon is the Developer versus Operations situation. To be fair, this is not new – even back when “Operations” was called “Systems” and it was all one big computer, there was a wall between the two disciplines.

I have long believed that this is a product of the fact that the intrinsic disciplines that these two groups represent are direct opposites. In other words, the creativity valued by developers is the direct antithesis of the rigor and consistency valued by operations folks. The conflict that this creates, however, is something we all recognize as being a necessary inefficiency. One side drives new solutions and the other makes sure the new solutions are available to users. When those two are in balance, projects succeed. When they are not, projects fail. So, if project success metrics are to be believed, things are catastrophically out of balance about half the time.

That is really unacceptable in any other area of business. Just as various line-of-business processes went through an alignment of supply chains and “just in time” inventory to make the actual business more agile and responsive years ago, tech shops are now working hard to become agile and responsive to the businesses they serve. The problem, of course, is that the wall between development and operations still exists. And the ops guys are still ‘preventers’ and the developers are still creators of ‘bugs and downtime’.

The times, they are a changin’

The movement to Agile/Lean/Scrum/etc. is actually driving fundamental change for the first time in a long time. Experience delivering highly dynamic web-facing services is showing the value of aligning development and operations into a single, coherent whole. We, here in Automation Land, have been discussing this indirectly for a while with our Build/Test/Deploy message and have been evangelizing the concept of “Dev Ops” for a while. For example, I created the image below about a year ago to help some of my development-centric colleagues visualize the “DevOps” gap and highlight where automation is valuable.

But DevOps is a much bigger movement and there is a confluence of technologies that is starting to turn shards of related ideas into a much more revolutionary set of topics. The three main drivers seem to be at the collision of Agile, VM/Cloud, and Automation. It is early days, to be sure, but Agile seems to be driving the change, VM/Cloud technologies to provide aligned infrastructure quickly, and automation to tie it all together.

What’s more, people are now gathering to proactively talk about this. It is no longer just vendors and consultants in isolation. I actually was at two events in the last 7 days where the “DevOps” collision point was a prime topic of discussion. The first was Opscamp where about 100 people participated in an “un-conference” all day Saturday to discuss modern operations issues. The group’s first topic suggestion was “DevOps” and there was an immediate, lively discussion of about 5 different sub-topics when it got written at the top of the flip-chart. There were several related sessions during the day. The second event was the regular meeting of Agile Austin where Redmonk analyst Michael Coté led a discussion around the dev-side perspective and how new technologies made it imperative for development to become truly involved and aware of operations in an Agile processes.

The common thread from both sessions was that the two groups must build bridges and understand each other. Everyone is truly in the same boat and infrastructure now must evolve with applications at the same rate. It is no longer acceptable for the infrastructure to behave as roommates – they must become a truly symbiotic individual.

There is one fly in the ointment, however. As you’ll see above, the Operations guys and the Dev guys still met separately. But at least they both talked about the same problem in similar ways. I personally hold out hope for the Dogs and Cats of technology to begin living together happily – if for no other reason than business and the speed of the modern technology marketplace will make them.

Follow

Get every new post delivered to your Inbox.