Contributors are writing from a personal point of view and all contributors are working for SourceLinq. SourceLinq is vendor of the leading Business Process Management Suite Aeon which is based on a Service Oriented Architecture. SourceLinq helps their clients execute on their strategy by aligning and execute their business processes efficiently. SourceLinq provides clients a complete Process Management Suite with advisory and implementation services on processes, content, people and technology.
The last couple of weeks I haven't bene posting anything on our blog. Shame on me! Business was quite hectic at SourceLinq and I didn't really had a lot of time writing posts for the blog. And guess what ... I will not make it up to you by writing an interesting post myself. I only want to bring to your attention a wonderful presentation of Rolf Skyberg. There are some nice quotes in the presentation (I copied this part from the blog of Martin Kloos) like:
“Web 2.0 is not a THING, but a TIME”
“we are surprised that teens are drawn to a place where they can listen to music, talk loudly, and express themselves without parental supervision [but in terms of Maslow’s hierarchy of needs, this makes absolute sense]”
“All business steal, but the business that steals the least, wins“
“the most succesfull of us will stop looking at the Internet as Web X.Y, but as a tool to cope with our inability to store, process, retrieve, and transmit massive amounts of information with other humans not near me”.
In my last post I was talking about one of the characteristics of a Service Oriented Architecture: Loose Coupling. Loose coupling is enabling what may come to be a whole new sector of the software industry, which goes by the name of software as a service (SaaS). With software as a service, the provider hosts the software for you so you don’t need to manage it or buy hardware for it. All you have to do is connect to it (by the Web) and use it. But before I get into SaaS in detail, first a little note about how we have come to SaaS.
Internet Resource Planning Over the past decade, huge investments have been made by medium-size and large businesses in implementing enterprise resource planning (ERP) systems using SAP, PeopleSoft, Oracle and other systems. While most traditional ERP systems have helped companies distribute business information internally, they have become obsolete in terms of the ability to share information not just within a company but with suppliers, customers, partners and shareholders. Additionally, these software systems usually require huge IT investments – an unaffordable option for most small businesses. But the next generation beyond ERP is here – called Internet Resource Planning (IRP) – and the time has come for small businesses to competitively participate in the IT race.
Marc Benioff (the CEO of SalesForce.com) describes IRP as follows: The ability to go across the Internet to share and manage all of your information that's relevant to your company, not just the information inside your company. Just focusing on the information inside your company is a very 20th-century idea.For example, our Aeon Management Suite (AMS) is a web-based application which can streamline entire business processes and put customers in the driver’s sear, while enabling companies to cut operating costs and concentrate on process improvement and service enhancement. What we see at our clients is that focusing only on the information inside the company is no longer sufficient. Utilizing the Internet allows our clients to monitor, deliver, share and manage all business related information with all constituencies, not just inside the company. So with our AMS you can for example integrate the supply chain and selling chain into one mega-channel which communicates with customers, deliver products and service customers
Okay, so IRP and SaaS are one of the new trends in the Information Technology. But what is SaaS exactly. If we take a look at Wikipedia we find the following definition: Software as a service (SaaS) is a software application delivery model where a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers pay not for owning the software itself but for using it. They use it through an API accessible over the Web and often written using Web Services or REST. The term SaaS has become the industry preferred term, generally replacing the earlier terms Application Service Provider (ASP), On-Demand and "Utility computing".
Licensing models An important aspect of software as a service is that it introduces a completely different license model to the computer world, a model that departs radically from the way customers traditionally acquire software. Basically, the way things have worked for years in the software world is that acquiring software meant signing on to a perpetual license for that software. Software as a service is sold on a subscription basis. You pay a certain amount every month or quarter and as long as you pay, you get what you paid for. If you stop paying, you stop getting whatever it is subscribed to. Nowadays we are used to pay for a lot of services – gas, electric, phone service and internet access for example. The new move towards selling software as a service means that software vendors are selling subscriptions rather than perpetual licenses
Our license model at SourceLinq is based on software as a service. Our clients can pay a monthly fee for each transaction which is done by the system. So our clients do not have to invest in servers, databases, administration cost or expensive software licenses. Besides this, our Suite is completely based on the Service Oriented Architecture so integration with existing systems at our clients is quite easy.
Myths So the future for SaaS and SOA looks bright, however when I talk to new clients I still see there are quite a few myths when it comes to the idea of software as a service. Let's debunk them.
Myth #1: My Data won't be secure. The primary fear IT encounters when evaluating a hosted model is data ownership and security. The fact is our hosting partners have more physical security, application security, firewalls, intrusion detection systems, processes and policies in place to protect data than could be mustered for an in-house deployment. Best of all, legally, customer data is owned by the customer, and we have no rights to look at the data. Myth #2: I Can't Integrate. For companies with many systems and processes that need to be integrated, integration between the Aeon Management Suite and in-house systems is easily accomplished via our AeonSphere, our platform enabling enterprises to integrate applications. Myth #3: I Can't Customize. Besides integration, AeonSphere also allows business users without technical skills to fully customize applications that precisely meet business requirements.
Below you can find a Youtube movie whichs explains Software as a Service in less than 3 minutes.
Both traditional packaged software applications as custom developed software systems (created specifically to solve a particular problem) share a common problem. They are not designed for substantive change. One pervasive characteristic that makes both kinds of applications especially brittle is just how intertwined the various programs that constitute the software applications are. The various programs are dependent on each other for little bits of code – without such bits, they cannot run. These dependencies were often created in the name of efficiency, especially in the past when hardware and memory were expensive.
However in the world of Service Oriented Architecture this has changed. Instead of a complete application which can be executed, the application is broken down into reusable services – components that can be used to build new applications. Of course this all sounds great; however it is not that easy as it looks like. The components (or services) should not have any dependencies or other functionality. The main idea is to ensure that each component carries out a single, easily understood function and should do nothing else. The goal is to create flexible composite applications that can be easily changed when change is necessary. However, that’s not possible if the components have multiple functions or have dependencies. At first it will take longer to write software without dependencies, but eventually it will be just as fast as the normal development cycle.
In the SOA world, everybody is talking about integration. But even before you can start thinking about integrating, you should think about deconstructing. Not only must you deconstruct applications, but also the business should deconstruct their processes by breaking them down into fundamental components. In the same way that the software components can be reused, the business components can be reused in lots of different business situations. So the world of Service Oriented Architecture does not only affect the IT-department but requires changes from the whole of the business. On the business side, professionals are often impatient to solve their problems quick (and dirty). The initial effort and time required to break down their processes (and applications) into components without dependencies may appear to take far too long. But if they want to be in a position to reuse the software they’re investing in, they need to invest in ‘doing the right things’ and ‘doing the things right'.
And to end this post I would like to share an hilarious movie from YouTube with you. It's called Greg the Architect - SOA This. SOA That.
Service Oriented Architecture is about Enterprise Service Buses and UDDI registries, but you should always keep in mind the whole point of a SOA is to make a business more manageable, more flexible and more responsive to change. The primary culprit when it comes to instigating change is business process - how businesses do things. Businesses are constantly changing how they do things - not necessarily changing what they do. For example, an insurance company might change the methods it uses to introduce new products or how it handles insurance claims - but, when all is said and done, it sells insurance. SOA enables businesspeople to change business processes without having to focus on the underlying technological plumbing. You can concentrate on designing and improving business processes by threading together business services. IT can build composite applications from existing business functions, adding other functions or making changes when necessary. Together, business and IT can determine the flow of work from one person to another (or from a person to a process or from a process to a person) within the larger business process.
So, how can you organize and design these business processes. Special applications (like our Aeon Management Suite) are available to manage these processes. These applications are called Business Process Management Suites (BPMS). BPMS is the modern approach to designing and managing business processes. The combination of SOA and a BPMS is extremely powerful.
With SOA, you want to harvest existing business functions by taking them out of their existing applications homes - applications that have provided the 'connective tissue' necessary to keep them functioning smoothly. The new connective tissue you need to house harvested business functions comes in the form either of the business process itself or of a composite application. BPM tools are critical here because they help you design and manage just such business processes.
Thus, BPM enables you to monitor business processes, which can lead to continuous improvement by identifying possible changes in a process that could result in better efficiency. Over time, more and more business processes are tied to software. When supported by SOA, continuous business improvement becomes a lot easier because the underlying software is 'loosely coupled', meaning that it can be modified more easily when required. When business needs to change in order to address strategic opportunities and threats, the flexible service oriented architecture facilitates the change.
I promised to post something on Service Oriented Architecture, however I just watch a clip on YouTube which I find very interesting. The clip is a live recording of the Keynote Speech to over 2000 executives attending SAP Brazil's 2006 User Forum in Sao Paulo. The speech is given by Jack Shaw who is talking about Innovation and the combination of People, Processes and Technology. Especially the example of the Transatlantic travel and the downfall of the Ocean Liners shows the huge impact of innovations on existing businesses.
One of the biggest deals in the Service Oriented Architecture world is the idea that you don't throw things out. You can use the same software assets that you use every day and package it in a way that lets you use it, reuse it and keep on reusing it. Of course you will one package the best part of your software assets. You shouldn't package everything. A good design phase is critical for your SOA project.
One problem common to many large organizations is that they have a lot of identical applications. Every time a department wants something slightly different than the available application, a new application will be developed. And what about the mergers & acquisitions? The last couple of years a lot of mergers have taken place. Can you imagine how many identical or almost identical applications are available in these large companies? With every merger the TCO (Total Cost of Ownership) increases dramatically.
Many IT departments have policies and procedures designed to prevent this sort of things to happen. However when deadlines loom and budgets are tight, it’s often easier and quicker to write something from scratch that fills the need rather than coordinate with other divisions. Besides this, some applications exist for years and when the initial developer is gone, new developers find it hard to understand the way the application is built no matter how good the documentation is.
Another fact about applications is they cannot be modified easily to the new requirements of the business. Say for example you make a change in business policy that affects the sundry applications. In this case you have to find and change each and every instance in every application that is affected. And even the slightest difference in implementation can result in inconsistencies – not a nice thing to find when the auditors come in to check your books.
How can the Service Oriented Architecture help you with this? The most important applications (or features of these applications) become business services. So for every given function a business service is available. This service can be used in any application in your organization. When we take the previous example of the change in business policy which affects the sundry applications, you only have to adjust it in one place. The modified service can be automatically used in every application.
In the picture below I have listed the characteristics of the old way (Distributed Component Architecture) and the new way (Service Oriented Architecture) software can be implemented.
The overall conclusion is that applications built in a service oriented way are much more agile and can be easily modified to the business needs. You now really have the possibility to implement and change your applications according to your own business processes!
I ended my last post with a little YouTube movie about the Service Oriented Architecture. In the same post I promised you to elaborate more an SOA from a business point of view. Well, in order to keep things straight first I will deal with some definitions. When I read an article about SOA on the internet, the author seems to be sure all the readers are familiar with the SOA definitions. I looked on google to find the meaning of some 'SOA'-definitions but it was quite difficult to find. So to start off with the whole SOA-adventure, it is a necessity you know what the IT-people are talking about.
Adapter: A software module added to an application or system that allows access to its capabilities via a standards-compliant services interface.
Business Process Modeling (BPM): A procedure for mapping out what the business process dies, both in terms of what various applications are expected to do and what the human participants in the business process are expected to do.
Enterprise Service Bus (ESB): The enterprise service bus is the communications nerve center for services in a service oriented architecture. It tends to be a jack-of-all-trades, connecting to various types of middleware, repositories of metadata definitions (such as how we define a customer number), registries (how to locate information), and interfaces of every kind (for just any application).
Service Broker: Software in an SOA framework that brings components together using the rules associated with each component.
SOA Governance: SOA governance is an element of overall IT governance and as such lays down the law when it comes to policy, process and metadata management. Metadata: Data that defines the source of the data, the notation to store the data (like mentioned before, a good example is how we define a customer number), the owner of the data and who can change the data.
SOA Repository: A database for all SOA software and components with an emphasis on revision control and configuration management.
SOA Supervisor: Software that orchestrates the entire collection of computers, network resources and software in an SOA framework so that they can run continuously at an appropriate level of service.
SOA registry: A single source for all the metadata needed to utilize the Web service of a software component in a SOA environment.
To end this post I would like to share this movie from youTube with you. It shows us how you can find the right partner by using process modeling software.
