The term "SOA Governance" has possibly become the most used phrase in the SOA community. However, through experience with the architecture
community across Product vendors, SIs as well as the Customers, is that it is also the one term that has been misconstrued to mean different things by individuals taking
a very silo-ed look at things. This article puts forward thoughts on the "What, Why, When and How" of SOA Governance based on experiences working at the grassroots level
of organizations with a successful SOA story as well discussions with the CXO organization on how they perceive the SOA story. SOA Governance is an embodiment of many
different aspects that are all crucial to the SOA story within the organization. Just as the standard "Governance" (whether political or organizational), SOA Governance
is also as much about policies and procedures of conduct as it is about the actual implementation, monitoring and control of the same...
While the technology platform plays a significant part in SOA governance adoption, addressing organizational aspects of SOA governance is even
more important. Building the correct structures, establishing the correct roles, and setting-up effective communication mechanisms are all necessary components for success.
No matter how tightly the technology is integrated throughout the entire project and service lifecycles, human beings establish, support, and execute the governance processes.
Governance is aimed to incentivize the right behavior and discourage the wrong kind. It is largely a process aimed to influence people in the organization. The technology makes it
easy to execute governance processes. However, a counterbalance is needed should people decide to sidestep governance mechanisms. This happens quite frequently for a variety of reasons.
Therefore, noncompliance should be expected and proactively addressed. The best way to achieve full governance compliance and adoption is to establish effective organizational structures
and incentives aimed at driving the expected behavior...
Activities and factors related to the SOA Adoption Planning are typically examined during the Project Establishment iteration in TOGAF.
This iteration consists of the Preliminary Phase and Phase A: Architecture Vision. The architectural inputs and objectives of these phases fit well with the objectives
of the SOA Adoption Planning. For example, the inputs of the Preliminary Phase include: scope of organizations impacted; maturity assessment, gaps, and resolution approach;
roles and responsibilities for architecture team(s); budget requirements; governance and support strategy; existing Architecture Framework, if any, including: architecture
method, architecture content (deliverables and artifacts), and configured and deployed tools; Architecture Principles; and Architecture Repository.The above correspond to
the inputs of the SOA projects. SOA provides explicit definitions and models for each of the above elements. Notice that the architecture principles are defined in the...
More companies are adopting SaaS applications, fuelled by a competitive business environment. When potential technologies emerge, companies need to adapt
them so that their IT departments can deliver innovative technology solutions rapidly at a lower cost. Frequently these days, we come across SaaS applications and providers. Core
business applications are hence gradually finding their new homes in clouds. In a recent article, Accenture has indicated that it has saved a lot of money for one of its valuable
customers by putting Oracle enterprise solutions in the cloud. SaaS solutions are also termed as on-demand applications that are attractive to IT because of the lower number of IT
resources needed for deployment and effective management. Business users can start using the new systems as SaaS solutions are intuitive and easier to tinker with. Also, everybody
likes subscription pricing because it means fewer budgetary issues get in the way of procuring and operating new applications...