Overview
Implementing Enterprise Architecture (EA) together with Service Oriented Architecture (SOA) can be very beneficial for an organization. Aligning the business and IT may reduce costs, lower risks, and help an organization become more agile. At the same time, wrongly implemented EA and SOA may create a risk of wasting a lot of effort, money, and time. Such risk can be mitigated to some extent. Avoiding potential traps on the way from the very beginning will help organizations avoid spending money to fix problems later.
Now, let’s try to identify some of the major pitfalls and the ways to mitigate the respective risks.
EA Risk Mitigation
2.1 The “Ivory Tower” syndrome
Some of the EA lead architects tend to spend a lot of time on detailed planning and modelling, being completely detached from the realities of an organization, living in a kind of “ivory tower”. To mitigate that, the enterprise architect has to make sure that the architecture being created is closely aligned to the organization’s business, IT, and budget. To get proper understanding and support, all relevant stakeholders must be engaged in the development of the business context, so that the business and IT goals are aligned. An architecture board should be formed to govern the implementation of EA and be a representation of the key stakeholders in the architecture.
2.2 Not the right person for the job
A lead architect who is an ineffective leader will not be able to bring people together. Ineffective leadership may result in chaotic architectural design, lack of progress or clarity of direction. The person in charge of the architecture needs to have strong soft skills, including communication abilities, a lot of enthusiasm and passion. He or she should also be well respected and strategically oriented. Another very important trait of the lead architect is the ability to “sell” EA to the decision makers so that they understand the value of the architecture and are willing to sponsor it.
2.3 Lack of governance early on
To identify, manage, audit and propagate all information related to architecture management, contracts and implementation, governance processes are required. If there are no governance processes established from the start, you run the risk that everyone will have developed their own working style, and that there are no monitoring and audit tools available to guide the architectural design. That’s why there is a high risk that the program will fail. The enterprise architect must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.
2.4 Communication problem
The key messages about EA are not always intuitively obvious, so the enterprise architects must work to educate the business. It is critical that there is an EA communications plan developed and implemented, which will convey messages tailored to each audience. The enterprise architect should communicate as often as possible, even if the artifacts being prepared are still in draft. What’s also very important, is that there be a feedback loop established, so the affected stakeholders have a chance to ask questions, challenge and debate openly with EA.
2.5 Focus on technology only
Putting too much focus on technology while designing enterprise architecture is a frequent practice in some organizations. Enterprise architecture is much broader as it includes business, information and solutions architecture. When technology and business goals are not aligned, you have the risk of non-technical people trying to make technical decisions with enterprise architects becoming too reactionary and tactical in response to projects. To overcome this, the enterprise architects should get involved in the development of the business context and engage jointly with other employees in the business architecture.
2.6 Doing the baseline current-state architecture first
When enterprise architecture is used to design a new enterprise vision and strategic goals, then you should not start with the baseline current-state architecture, as enterprise architecture provides prescriptive guidance, while current-state architecture does not. This will result in delayed delivery of the enterprise architecture value and will hinder the creation of good future-state architecture. So, try to establish the business context and focus on future-state EA first.
SOA Risk Mitigation
3.1 Governance
Services have a lot of potential for providing benefit to the enterprise, but their use brings a level of risk as well. Some of these risks are financial, while other are operational. All can be satisfactorily mitigated through appropriate governance activities as follows:
- Project portfolio governance coordinates the investment (creation of services) with ROI (the second and subsequent uses of a service).
- Service design governance ensures that each service actually makes sense. It explores the potential uses of the service and makes sure that they are similar enough that a common service will provide benefit.
- Project governance ensures that projects use services where appropriate.
- Operational governance ensures that someone keeps an eye on the service after it has been placed into operation.
3.2 Information assets security
SOA increases risks associated with information assets by exposing such assets more readily to a broad audience. While this is beneficial to business operations, it is a cause for greater concern for security and risk management professionals. To mitigate this risk, it is critical that the SOA governance team partners with risk management teams to assess risks that are brought about or intensified by SOA.
3.3 Interoperability
Interoperability is another key risk of a SOA. Despite the promise of Web services, organizations will discover that not all Web services are truly compatible. Moreover, software products that function as “Web service adapters” for existing applications may not always interoperate with other Web services. As your organization moves towards SOA implementation, you should monitor the efforts of the WS-I organization (The Web Services Interoperability Organization). The core mission of the WS-I is to be an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. While such efforts help prevent instances of incompatibility in the future, you will need to consider how to handle instances in which services do not interoperate properly. How will you deal with these exceptions? What are the best practices for ensuring interoperability in the future?
Conclusion
As mentioned at the beginning, both Enterprise Architecture and Service Oriented Architecture may bring a lot of value for an organization. At the same time, numerous initiatives of this kind fail. But failure doesn’t have to be inevitable. Many of the pitfalls can be avoided and many challenges can be overcome. In this article, we have tried to highlight the major examples of such pitfalls and challenges and explained how the respective risks can be mitigated.
