Welcome to MSDN Blogs Sign in | Join | Help

Inside Architecture

Notes on Enterprise Architecture, Systems Integration, and anything else that interests me this week...

Browse by Tags

All Tags » BPM   (RSS)
How do you measure Enterprise Architecture?
One thing that I've come to truly appreciate: the balanced scorecard.  Don't get me wrong: I've been using scorecards and dashboards for over a decade.  I helped to build one at American Express.  But I have come to see, from an executive Read More...
An examination of the OMG Business Motivation Model
Contrary to popular belief, Microsoft loves standards.  We don’t always play well with standards bodies, but it doesn’t mean that, operationally, we don’t benefit as much as the next guy from standards.  From an IT perspective, we cannot be Read More...
Feedback requested: Information driven process design
An esteemed associate of mine asked me recently if I believe that a conceptual information model, created and delivered independently from a process model, can be considered useful when attempting to improve a business.  In other words, if you have Read More...
Input sought: Actor - Role - Process Activity... an interesting domain model question
I have an open question. I'd love to get community feedback. A process can be decomposed into activities. Who performs the activities? Are activities performed by roles with actors assigned to those roles, or are activities performed by actors in roles? Read More...
Clarifying the Concept of Metadata
Metadata is a difficult word to define, or so it would appear. After all, why is it that the best that Wikipedia can do is: Metadata ( meta data , or sometimes metainformation ) is "data about data", of any sort in any media. An item of metadata may describe Read More...
How BPM does, and does not, support people
Kudos to Andrea Westernien on her blog about the disjoint between the work that people do and business process automation . Andrea, who blogs under the title of 'Policy Based Business blog,' used eloquent words to capture what I was originally trying Read More...
Working in the dark
If we listen to smart people who create development processes, we hear things like "collect requirements" and "understand business process."  We then go and write use cases, design software components, and write code.  Test Read More...
Using Business Process Models as the source for software requirements
Requirements elicitation is a critical, yet under-appreciated, activity.  A core capability of business analysts, the ability to get the customers to describe what they want, and need, is both a science and an art.  Requirements elicitation Read More...
Growing Rice in the Desert - the Garden of BPM
Apparently, I ticked off Bruce Silver . In case you haven't heard of the fellow, as I had not, Bruce is a consultant who makes his living providing training on BPM tools and his advice on BPM products. At least, that's the impression I got from reading Read More...
Preventing Ownerless Activities -- the "Blame the Computer" process modeling antipattern - part 2
In a prior post, I described a process modeling antipattern which I called " Blame the Computer ." The feedback helped me to realize that there's a deeper problem that we need to consider: alignment of ownership between process and IT. Ownership of a Read More...
Why Automated BPM will never live up to its hype
I like point out really nutty ideas, even when a lot of people have spent a lot of time investing in them.  This one is about expectations. About 15-20 years ago, a great many companies starting investing in "Business Process Management" Read More...
Blame the Computer: A Business Process Modeling Anti-pattern
Whenever you model a business process, it is inevitable that, sooner or later, you will come to an activity that is entirely automated. As time goes on, more and more of the activities slip quietly into the technology. However, I'm noticing a troubling Read More...
Example of modeling requirements in a process diagram
We use process models for lots of things. One is simply to understand the processes we have and to analyze them looking for opportunities to improve. But in IT, we have another good reason: to better understand software requirements. One goal that we Read More...
IT to Business: "I won't read your mind"
In any relationship, it is dangerous for one side to "decide" what the other one wants.  Marriage advisors say things like "Don't control others or make choices for them."  Yet, I'd like to share a story of technologists Read More...
Leaving technology out of requirements gathering
I'm going to suggest a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner. A little background In the systems space, it is common to write up a "requirements document" that attempts Read More...
More Posts Next page »
Page view tracker