What causes a company to change? It could be something as large as a merger or acquisition, or as small as deciding to use less paper around the office. Sometimes change can be scary, in part because it tends to shine a light on the dysfunctional processes within the company.
For example, when planning for change, a company might notice that they have been following a process that no longer is relevant or efficient. Too often a process is accepted, even if it is a dysfunctional one, which ultimately impacts the bottom line. If companies are not evaluating their operational processes on a constant basis, adapting to change will become more difficult.
Establishing regular evaluations of business processes will give more control over operations and help reduce the “fear factor” of having to make a bad decision while adapting to change. That said, evaluating processes requires having complete visibility to them. To do this, companies who have fully integrated their systems and application data will be able to see where their workflow bottlenecks or drop-offs are.
With a single integration tool connecting the entire organization, any department can view the health of operational processes. Automated notices can be set up to alert specific people of process disruptions, while dashboard views and on-demand reports can be called up by anyone, from the IT Manager to the CFO. Looking at data moving through the entire organization gives companies a global view over whether invoices were received, bids were answered on time, or even to check against a chargeback claim.
Whether companies strategically change for growth, or reactively change from market pressure, evaluating current process efficiencies will be at the top of the change plan. Utilizing integration to proactively maintain healthy processes will not only keep the pain of adapting to change at a minimum, it will certainly help companies achieve growth much faster.
In my last blog, I talked about UDDI (Universal Description, Discovery and Integration) including where it’s been and where it might be going. In this article I’m going to take a different look at UDDI and consider the question, how useful is it to find what you’re looking for? One aspect of UDDI that has been overlooked by OASIS (Organization for the Advancement of Structured Information Standards), the Web Services standards body, is how to find services faster and more efficiently.
UDDI allows service providers to publish data about themselves and their Web Services, and supports simple searching for services. The standard UDDI search uses a single search criterion, such as business location, business name, service type by name, business category or business identifier. This limits the efficacy of UDDI for general service discovery. An example is searching by business category; the search might return the service you want, but you might need to filter the results to find it. Continue reading
I get asked the same question every couple of months: Is UDDI dead? For years, people have been discussing UDDI and the lack of use that will cause its death. Here’s the back story on UDDI.
UDDI stands for Universal Description, Discovery and Integration, and it is an XML-based standard for publication of service listings and their subsequent discovery by service users. UDDI is often compared to a telephone book with white, yellow and green pages, it and allows businesses to list themselves by name, product, location or the (Web) services they offer.
In this blog, the age old discussion of “Which is Better: SOAP or REST?” will be discussed, and challenges associated with your decision. I’m going to list advantages and tradeoffs of each, but first let’s start with a little background information little background information.
What is a REST Web Service?
The acronym REST stands for REpresentational State Transfer, meaning each unique URL represents some object. The architecture was developed by Roy Fielding, one of the authors of the Hypertext Transfer Protocol (HTTP). A REST Web Service uses HTTP and supports the HTTP GET, POST, PUT or DELETE methods. Continue reading
Today, I’m going to take a look at SOA (Service-Oriented Architecture) from a different angle that is often overlooked. SOA governance is sometimes an after thought, though critical to the enterprise.
SOA governance is best defined by Anne Thomas Manes as: “The processes that an enterprise puts in place to ensure that things are done … in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA.”
One of the risks that emerge as more and more applications become integrated is the spreading of bad data (e.g. invalid, incomplete, etc.). Misinformation and bad data constantly challenge organizations today. Engaging in SOA activities without consideration for governance is like opening up a four lane highway with no cops to patrol it. Controlling life cycles and versioning, governing people, policies, design-time, run-time and processes to establish and maintain desired behavior are examples of SOA governance. Continue reading