We frequently debate the question of who owns business architecture, but this question hides a more fundamental issue that can dramatically impact the value proposition of business architecture. Motivation and intent will ultimately determine if business architecture is a “game changer” or just another management discipline delivering incremental improvements to the status quo.
Organizational Culture to BPM Automation (Pillar Three)
“The culture of paper in a business today is still considered important, as a means of support and evidence of any activity carried out within an established process. The change into a culture oriented to the use of information technology is mainly based on the commitment of the end user to live in an environment of automated activities and operational activities within the process where paper is used mainly in necessary control processes.
SOA and Service Management
Within the world of SOA the term service management usually refers to the control and orchestration of the invoked service (web. Business, composite, etc.), usually called SOA governance.
Instituting Change
This article may seem at times like a rant. It’s not meant to be. It just deals with the frustration that all of us who innovate in the development of planning processes feel when the most rational, carefully-planned, sure-fire, absolutely-self-evident advanced planning methods fail to stick in an organization!
Being Intelligent with SOA: Using SOA to Lay the Foundation of your Business Intelligence (BI) Initiatives
SOA purists might scoff at using SOA for integration [1], but for many enterprises, Service Oriented Integration (SOI) remains one of the prime motivations for embarking on the SOA journey. Agreed SOI by itself doesn’t achieve the avowed goals of agility or elimination of redundant IT infrastructure, but it helps the enterprise address real concerns, now. The SOA Manifesto [2] states that Business value is of higher priority over technical strategy; hence easier integration with SOA is a valid goal of a SOA initiative.
Manage the People or Manage the Process?
When you are trying to handle a problem, make an improvement, change the culture, or implement a key strategy where do you go first – to manage the people or manage the process?
Consider these four scenarios. Would you approach the situation by managing the people or managing the process? Rate each one against the 5 criteria and think about why you selected the rating. We will come back to these four scenarios at the end at the end of the article and consider them further.
Changing – A Core Business Competency
With the operational problems caused by the current economy and the uncertainty that possible new legislation is causing, the need to change quickly and effectively is greater than ever. Few companies are prepared or capable of rapid, efficient change – especially broad based change.
Putting Business Information Architecture to Work
In a previous article, we talked about using web semantic technologies such as OWL and SBVR to create conceptual models of a business. In this article, we explore an example of using a Business Information Architecture to solve a business/IT problem. The architecture exercise helped clarify thinking about the possible solution forms and served as a model for the corresponding IT application and data changes.
Can SharePoint 2007 be my Enterprise Business Process Management (BPM) Solution?
SharePoint 2007 provides a basic set of business process management (BPM) functionality. Many IT shops and business users who have SharePoint 2007 running in their environment may be wondering what BPM capabilities SharePoint 2007 does have, and how it stacks up to traditional packages that promote themselves as complete BPM solutions.
Most Enterprise BPM solutions are comprised of the following high level components:
Six Simple Steps for Accelerating and Perfecting Requirements: A Framework, a New Model, and Visualization
Software engineering is a much younger discipline than are other branches of engineering. We see this in the continuing evolution of attitudes and approaches to requirements. In early days, there were no requirements. In later days, there were volumes of approved textual statements. Eventually, there were formal models. Today, sometimes models and statements are merely interim deliverables because code becomes the requirements.