Business Architecture is a key decision tool for organisations and could be thought of in a similar way as GPS systems—being a ‘navigation system for business’. It allows static blueprints to be transformed into dynamic models for greater insight than ever before. With business managers in the driver’s seat, different questions will be asked from the traditionally technical ones normally associated with EA. In order to support these questions a different approach to tools and solutions will be required.
For decades, corporate executives and department managers have complained about the frequent budget overruns and schedule delays of complex IT business planning and transformation projects. The fact that these costly undertakings often fall short of providing the expected business objectives only serves to increase their frustration. Underlying causes include the complexities of modern organizations, intricacy and size of applications, as well as miscommunication between business, operational and IT experts who each speak their own jargon.
Interviews from over a thousand CEOs in 2008 shows organizations are bombarded by change, and many are struggling to keep up1. CEOs view increasingly demanding customers not as a threat, but as an opportunity to differentiate. They are moving aggressively toward global business designs with deeply changing capabilities and increased flexibility. The gap between their capability to manage change and the challenge ahead is growing. CEOs expect fundamental change, but they seem uncertain about their organization’s ability to manage it. Business pressures are compounding as IT constraints are growing.
As enterprises continue to deploy business architecture capabilities, the need for a consistent, cohesive understanding of business architecture is growing increasingly critical. Frameworks, methodologies and tools will continue to evolve, but practices and technologies must be based on a solid foundation. This white paper promotes a common understanding of business architecture. The discussion defines the essence of the business architecture, how it relates to IT architecture, the importance of business architecture standardization, and a roadmap for achieving standardization.
TELUS is a leading national telecommunications company in Canada, with $8.4 billion of annual revenue and 10.4 million customer connections including 4.7 million wireless subscribers, 4.6 million wireline network access lines and 1.05 million Internet subscribers. The company's strategic intent is to unleash the power of the Internet to deliver the best solutions to Canadians at home, in the workplace and on the move.
This paper focuses on solving the dissociation between business processes and business requirements. While a projects must have good analysis, pragmatic risk assessment, a sound business case and reliable measurement tools if it is to have any hope of succeeding, business processes and business requirements are inextricably linked to a company's vision and the project itself. Closely coupling business processes and the business requirements of a new application are not only desirable, they are inherently critical. Business software applications are tools to aid business processes.
This paper is about why software development methodologies don't work and why they sometimes do, including a few ideas about how to turn around your own methodology efforts. Often, methodologies don't work because managers and IT professionals hold onto beliefs, practices and organizational paradigms that no longer fit the modern software development organization and the processes that help support it.
How do you feel after reading the business section of the newspaper or your favorite business publication?
As organizations confront increasing complexity in their business environments, business leaders seek out technologies that allow them to automate, monitor, and optimize key processes across the enterprise. The ability to quickly develop business rules that not only define how these processes are executed, but also to drive customized user interfaces, tasks, monitoring, and automated processes have become key elements in business process management (BPM) application development.
Enterprise architecture (EA) and IT Disaster Recovery Planning (DRP) are seldom combined in the same sentence much less integrated activities within a company. In this paper, a case will be made for the integration of these two critical business activities as well as promoting a unique business recovery planning philosophy. This paper outlines a logical approach to understanding a company as a system comprised of processes and tasks and then extends this to an approach to creating a comprehensive enterprise architecture.
