The reasons to replace an existing system may be technical in nature such as upgrading the platform or notice that key software will no longer be supported by the vendor. Or, it may be due to changing business conditions and the need to respond quicker in an increasingly more dynamic market and customer demands. In these cases, the decision to replace the system is often accompanied by a mandate that there be no change to the underlying business process.
How Do We Do Requirements?
Attending the recent IBM Rational Conference, I listened to some very interesting conversation around the subject of requirements – Rational now has not one, not two but three different “Requirement” tools – its ‘legacy’ product, Requisite Pro, the newly acquired Doors product from Telelogic (now an IBM company) and a newly announced “Requirements Composer”, part of its new software development portal dubbed “Jazz”.
Defining the term “Business Architecture”
How does one define the term “Business Architecture” (BA)? Before an enterprise undertakes a Business Architecture initiative, it must have a clear understanding of what it is and how it is defined. Perhaps by first parsing the term “Business Architecture,” and then characterizing it as a whole and complete term, one can bring clarity to its definition. And of course, the Business Architecture requires an association and some context with the enterprise as well. This article will offer one perspective on the definition of Business Architecture; hopefully, stimulating
Creating Momentum for Process Change
In our consulting work at the Performance Design Lab (PDL), we have frequently talked with clients who describe the following scenario: “Our improvement projects usually seem to get stuck between current and future state. We get the ‘is’ process mapped out okay, but we can’t beyond that.”
The question we always ask is, “Why did you start the project in the first place?” What we find out is that processes often get mapped without any clear purpose, other than to map them.
Improving Government Service by “Building Sidewalks Where People Like To Walk”
A few years ago, a private liberal arts college in Vermont decided to reinforce the image of its campus, which features lots of quads and open spaces, as one that encourages students to do more walking. Concrete walkways were built over existing dirt-paths that the shoes of students and faculty had been shaping and re-shaping for generations. When the renovations were done, the local newspaper reported that fewer students showed up in class thereafter with muddied sneakers, though more of them were walking across the campus, even on rainy days.
Avoiding SOA Security Anti-Patterns: Practical Planning for Success
As important as information security is, it seems to be one aspect of SOA that is too often overlooked. Without a well-thought out security plan, a SOA project will introduce critical vulnerabilities to the enterprise, it may require a large amount of time and resources in order to “retrofit” security later, and it may never be deployed at all due to accreditation failure when there are unmet needs related to mandatory security rules and privacy laws.
BPMS Watch: Which Way for BPMN?
To the surprise of nearly everyone, OMG’s Business Process Modeling Notation (BPMN) has emerged as far and away the most important standard in BPM, driven in large part by the BPM Suite vendors who recognize its value as a bridge between business-oriented process modeling and implementation design. Today, for example, BPMSs ranging from Appian, Savvion, and Lombardi to BEA, Oracle, SAP, SoftwareAG, TIBCO, and Vitria layer rely on BPMN-based modeling as the underpinning of their process implementation design.
The Five Implementation Options to Manage the Risk in a New Process
How do you manage the risk and uncertainty concerning a new process design? Below are five options ranging from low-risk suggestions to ones that imply higher risks.
Role-Playing, Practice, and Simulation
The least risky option is to role-play, practice, or simulate the new design. To use a military metaphor, you wouldn’t be using live ammunition in this option. A professional football team employs this option (and calls it practice) Monday through Saturday. There’s no risk in role-playing, practice, or simulation.
Introducing the Jiffy Lube Metaphor of Continuous Flow
Are your software implementation efforts woefully behind? Are your development schedules constantly being compromised by increased demands from other business units?
Does SOA Kill Capacity Planning?
In theory, computing capacity should be like water, if you need more just leave the tap running a little longer. All manner of virtualization, grid and attached processing technologies are being developed and deployed in an effort the make this theory a reality. Therefore it would be easy to assume that capacity management would not be an issue for SOA. Just deploy the services and SOA infrastructure on your tap water computing power with a few automation policies and capacity management ceases to be an issue.
What a lovely fantasy.
The real world, unfortunately, does not work that way.