Author: Ed Sable

In today’s competitive world, organizations strive to bring in the best blend of the technologies to drive their business forward. SOA is a hackneyed acronym for technology enthusiasts, however, if you ask two people to define SOA, you’ll hear different or conflicting answers. Some of them consider SOA as an IT infrastructure that enables business while others define SOA as a means of increasing the efficiency of IT. So what exactly SOA is meant for? SOA or Service Oriented Architecture in simple words is a loosely-coupled architecture designed to meet the business requirements of an organization. Previously, loosely coupled architectures depended on technologies like CORBA, DCOM or document based EDI approaches for business integration. However, these technologies mostly got replaced with Web Services. So, from an organization’s perspective, SOA may consist of a group of Web Services with common capabilities such as logging and authentication. SOA is an architectural approach to building systems from autonomous services enables agile business process through open standards interoperability SOA allows IT to respond to the changing market conditions and being an architectural philosophy may not be implementable always. Organizations should align SOA with the business drivers to reap benefits and here we unfold some myths and facts associated with SOA. Myth Fact Organizations can buy SOA Organizations can utilize tools to automate parts of the service lifecycle, however, this doesn’t provide an SOA.  SOA is a new and revolutionary technology. SOA is actually a design philosophy that is not dependent on vendor, product, technologies or industry trend.  SOA is common across organizations. SOA varies from organization to other. Purchasing SOA infrastructure from a single vendor hampers the purpose of investing in SOA.  SOA always require Web Services.  SOA can be implemented with Web Services but doesn’t always require it.  SOA is a methodology that aligns IT and business.  SOA is not a methodology and it’s a means of delivering the solution and not your end goal. SOA needs a technology and business process overhaul. SOA should be built on your current investments and is incremental.  SOA reduces implementation risk. SOA is implemented across organizations in different ways and may not necessarily provide the best-fit solution.  An Enterprise Service Bus (ESB) is required for SOA. SOA and ESB are complementary technologies. ESB is a tool that can be leveraged to implement SOA design patterns SOA solves all integration problems.  SOA will only solve integration problems as a result of tightly coupled systems. SOA is expensive. SOA projects tend to be cheaper and faster. It generally increases the reusability of services.  SOA can be deployed globally.  Due to technology and governance pitfalls, SOA is not good for global architectures in organizations with multiple trade locations.   Services are basic building blocks of SOA however, these doesn’t need to be web services. The SOA concept can be viewed from several perspectives and from a holistic point of view, these perspectives help in understanding the underlying architectural requirements. SOA may not be a panacea for every business or IT problem in the organization. SOA significantly holds benefits for enterprises that approach it methodically. A well planned and executed SOA undertaking will help organizations to achieve better responsiveness in a dynamic market landscape. CLICK HERE to learn how SOA can be applied to your business.

Communication is critical to custom software development project success. For the duration of the project, you and the vendor are a team. Effective, honest communication depends primarily on the personalities of the stakeholders and developers involved, and can be far more critical than the particular custom software development philosophies, methodologies, and technologies used. Here are the top ten questions to ask any potential custom software development firm: 1.      Are you associated with certain technologies or vendors? It’s unfortunate, but some custom software development companies favor certain technologies, vendors, or solutions, even when they may not be right for your project. 2.      Have you done something like this before? If they have, great – but make sure it really was similar, and was done well. Do not hesitate to ask for references, call prior customers, and do the usual due diligence you would with any new vendor. 3.      Do you guarantee your work? If so, how, and for how long? 4.      Have you ever read the licensing agreement for a piece of commercial software? Most of them amount to: no warranty expressed or implied. This is unacceptable for custom software development projects. 5.      Who will do the work? Can I meet them? If you’re going to have to interact with the project team significantly, it’s important to know who they are and how well you get along. Communication is key, and the longer the project, the more these relationships will matter. 6.      How Much? What is the total cost – no hidden costs! Expect the answer to be a range. 7.      How long is the project going to take? How long will the project take, in calendar time? How often will they report progress and what intermediate results will you be able to see/approve? 8.      What type of Security will be in place? Who will have access to your data and systems, and why? What steps will be taken to protect proprietary, personal, secret, and/or vital data and systems? What are the repercussions for violations? 9.      What Happens Afterwards? Will they train your users? What will they charge for bug fixes (past the guarantee period) or minor enhancements? 10.  Will your system use or depend on third-party libraries or systems?   Here is a bonus question to ask yourself… Are you excited about working with them?