The Service-Oriented Media Enterprise
April 14, 2008
We love our systems. Their growing complexity is something that, while it may awe us, we should all be concerned with. Author Douglas Adams said, “The world is a thing of utter inordinate complexity and richness and strangeness that is absolutely awesome. I mean the idea that such complexity can arise not only out of such simplicity, but probably absolutely out of nothing, is the most fabulous extraordinary idea.” In many ways, this should sound familiar to those of us who have been managing systems for some time.
Last month, a book was published that I wrote with National TeleConsultants colleague Joey Faust, titled “The Service-Oriented Media Enterprise.” It is about how the broadcast and media industry can apply Service-Oriented Architecture, Business Process Management, and Web services to the media systems we design and maintain to reduce complexity. These solutions also enable us to increase our agility to respond to new business requirements. In the next few columns I am going to be writing about these concepts and giving you some ideas about how you can apply them to your systems.
One of the things being seen more and more is the need to make changes to our systems. This has always been true, but the usable life of any given technology is shortening and the business requirements for our systems are changing more quickly than ever. In addition to your day job, you need to support the Internet, mobile and more. The business you work for is demanding ever-increasing agility from the technology you are responsible for.
One way to deal with systems is to just keep building them and doing things the way you have always done. A lot of the systems we have built look something like Fig. 1. I bet that this diagram is conceptually familiar to you. We have many departments or systems connected together in a variety of ways (IP protocols, flat files, e-mails, paper forms, etc.) that have grown more complex and interdependent over time as the facility has evolved.
| Fig. 1: Tight coupling without SOA|
This is not to say it doesn’t work. It works, but the resulting complexity is not without penalty. What happens when you need to make changes to this spider web of people and systems? When you need to add new systems to meet new needs? When you need to upgrade software? When you need to retire end-of-life systems?
As we all know, each of these changes is usually a somewhat daunting experience. We fret over the interaction of these systems after changes. We fret over unintended downstream consequences of an upgrade. Will something important be broken and bring the whole thing off air? This natural sensitivity to change in a system is because the communications between the systems are tightly coupled, and this creates a kind of fragility that makes those of us responsible for these systems reluctant to make necessary changes.
WHAT TO DO
What we need to do, really, is not address each individual change, but address change itself within our systems and our processes. In order to meet the business needs for rapid change, we need to find a way to make ourselves less resistant to changes. What would be ideal is an architecture that is “loosely coupled” and allows us to make changes without affecting every system. We need one that is standards-based and minimizes the impact of changing out one system for another. We need one that actually helps us create reusable components in our overall system that can be put together in different ways for different workflows, giving flexibility to how we work. By having reusable components, we get the most out of the systems we buy.
SOA is just such an architecture or approach, as seen in Fig. 2. It is a big concept, but the basic idea is that the interfaces to systems are “wrapped” to enable them to present a single interface to a common messaging bus. This means that there is only one place to make changes when changes need to be made. The systems involved need not be brand new SOA-ready systems. The systems that are wrapped can be the same legacy systems you use every day.
| Fig. 2: Loose coupling with SOA and a middleware layer|
What the interface actually presents to the outside world is reusable business services that make sense to your business. These can be orchestrated in different ways to create new workflows. For those of you with programming experience, this is kind of like object-oriented programming at the application level. There can be services like Get Media or Transcode Asset to Mobile or Bill the Client, or anything you really do day-to-day in your business. A single system can present many services.
This is part of a larger trend of bringing technology more in alignment with business. SOA has become more important in recent years in part because IT bodies such as OASIS and the W3C have done so much to standardize the technologies involved in SOA, such as Web services. This has helped adoption to become rapid and widespread.
This architectural style is very popular in IT and there are many, many more systems coming online every day that are built this way. It is almost guaranteed that at some point in your day-to-day activities you will come in contact with a system that was built in a service-oriented way. It is very important that you look at this concept and learn more about it. It is coming up more and more in our industry. There are media products that are being built with service-orientation in mind. There are a number of systems in large media facilities that have been built with SOA principles and technologies. BPM, which I will be discussing in my next column, is a set of best practices and technologies that simplify, automate, and optimize workflows in an SOA.
This is something we truly need more of in our industry and it isn’t just the latest buzzword. You can apply the principles of SOA to simplify your life.
Leonardo da Vinci said, “Simplicity is the ultimate sophistication.” Be sophisticated! Simplify your systems with SOA. It is important for your future. You can count on IT!