by Adam Boczkowski
Part of the Oracle Experiences in Enterprise Architecture article series.
Published February 2011
Enterprise architects are not typically asked to define or optimize business processes, but they do need to be equipped to understand those processes in relation to their organization's overall business strategy. This knowledge helps to ensure that each department conforms to consistent business practices, processes and standards. EAs maintain a cross-domain perspective that represents the vision and requirements of the organization as a whole.
ICON is a case in point. Based in Dublin, Ireland, ICON is a global clinical research organization that manages clinical trials in all major therapeutic areas throughout the entire drug development and approval process. Its customers include the world's top 20 pharmaceutical organizations and all leading biotechnology companies. ICON's clinical trials can be seen as long business processes with multiple phases that can take up to five years to complete. In this highly regulated industry there are lots of rules governing how data can be sent, received and shared.
ICON looked to Oracle for help enforcing consistent, cross-domain data-management practices to eliminate the lag time between each phase of the clinical trials process. They knew that streamlining these intervals would reduce time to market for new drugs and maximize market penetration. To speed up this cycle, they began by analyzing how data is collected, who the key stakeholders are in that process, and which compliance issues to address.
Oracle's EA team compared ICON's data management practices with the practices of other innovative firms in the health sciences industry. ICON knew how its processes worked, but had never carefully documented them. These industry examples provided a platform for establishing best practices and a model for structuring future development projects. In later phases, this model helped ICON to quickly spot problems, identify opportunities for innovation and convey the potential benefits to stakeholders throughout the business.
The engagement at ICON involved a mixture of macro and micro governance. In order to add value to those processes, the EA team had to fully understand the clinical data management processes and their impact on the profitability of the organization as a whole."The output was fantastic," says Mike McGrath, VP of Group Information Technology at ICON PLC. "I have to admit I was skeptical that a vendor could do an impartial review of our IT architecture that didn't evolve into a sales pitch. This was an extremely professional and worthwhile exercise that has changed our perception of Oracle as a partner and not just a vendor."
As ICON learned, it is important to understand the difference between governance in the context of discrete business processes (micro governance) and governance in the context of broad EA strategy initiatives (macro governance).
Macro governance provides the structure and processes for implementing an organization's business strategy and objectives through enterprise architecture. An EA governance body typically guides each project to ensure architectural alignment during IT transformations and solution implementations.
Micro governance involves examining specific processes within a specific context to help people examine the overall operating model of a company and the key core processes within that company. You may not see the wider impact of that process on the organization as a whole unless you fully understand where it fits into the organizational processes.
While Enterprise Architecture does not necessarily include business process optimization and design, it has a clear role to play in the governance and monitoring of these processes, especially when they involve cross-domain IT capabilities. To truly add value, enterprise architects must always consider the context of their examination of specific processes. EA specialists are typically not process analysts. They define how a process interacts with other core processes, and how a process impacts the organization. To do this well they must understand the external and internal factors that influence the organization. External factors include things like compliance, which are imposed from without. Internal factors include specific IT standards and operational business requirements.
To be credible, enterprise architects must converse with business leaders using terms they readily accept and understand. They must fully understand the business processes and know who is responsible for those processes, even when they span multiple lines of business.
For example, EAs should be able to demonstrate business value through performance metrics that business leaders recognize. While the metrics that appear on financial statements are very significant to senior business executives, it is often difficult to describe all the benefits derived from EA using only financial metrics. It is the responsibility of the chief architect to understand what drives business value within their organizations and to share this knowledge with the business sponsors, helping everyone to work towards agreed upon goals as they plan, align and execute the business strategy being pursued.
Business process management (BPM) tools can facilitate these activities while enabling organizations to react to fast changing business environments. Embracing BPM will help EAs extend their influence within an organization and ensure a wider-ranging and more effective governance regime. Enterprise architects can incorporate BPM governance within their overall EA governance portfolio to influence business process discovery, design and operations-leading to improved operational excellence and business agility-without compromising the principles of a wider EA governance role. Having solid governance practices in place makes it easier to anticipate business and IT risks and ensures compliance with corporate strategies, policies, and statutory regulations.
Business architecture focuses on business processes along with the organizational structure and operational model. You must also understand the relevant master data elements. If you're working in HR, it's personnel data. If you are working with CRM, it's customer and product data. All of these things are fundamental to understanding business processes.
About the Author
Adam Boczkowski is a Director of Enterprise Architecture at Oracle Corporation.