Too often, as business architects, we face internal barriers while driving adoption of business architecture practices within an organization. We are confronted with confused looks, competing priorities, tight budgets, and hearing frequently that “we don’t need another documentation methodology.” All are fair points if the perception of business architecture is truly that it is only a documentation methodology. Business Architecture, however, is much more. It is easy for any business architect to get preoccupied in the daily routine of producing business
When BPM is Not Done Right
Much of today’s Business Process Management (BPM) consideration and effort tends to focus more on the technology aspect. Truly effective BPM, however, cannot focus entirely on technology.
In this article, we will explore three aspects of BPM that do not get as much attention as they should: the human-side perspective, the need to implement incrementally, and the place of BPM within the larger context of Business Transformation.
Business Architecture and Portfolio Management
Fiona S., the chief operating officer of an multi-national industrial parts manufacturer, listens to Wayne, the vice-president of sales, present his group’s capital investment proposals for the coming year. Among the planned initiatives Wayne describes is the development of an online sales quoting tool. As Fiona listens to Wayne run through the list of proposed features that the tool will include, a thought occurs to her:
Didn’t the Customer Service group propose a CRM initiative that touched on similar things just last week?
Maturity & Business Architecture
Background “Maturity” is a term that has become more and more prominent in business since the 1980s, when the United States Air Force funded a study at the Carnegie-Mellon Software Engineering Institute to create a model for the military to use as an objective evaluation of software subcontractors.
The Watermelon Box
“Innovation” does not always mean “new technology”
There’s almost nothing better on a hot summer day, especially at a picnic, than a nice, cold, juicy watermelon. The problem with watermelons, however, is that they are big, oblong objects that usually don’t fit in the fridge and often take up the whole ice chest (occasionally, you can find a smaller, volleyball-shaped melon, but even those take up a bunch of space).
Business Architecture: The Complete View of Business
In recent years, two business evaluation methodologies have competed for center stage: Business Process Management and Business Rules Management (or, as some are now calling it, “Business Decision Management”). Currently, there is a new methodology, Business Architecture, which is attracting attention.
Why is Business Architecture generating such interest?
What Makes a Great Business Architect?
“What makes a great business architect?”
“My organization is looking to hire business architects. What should we be looking for?”
“How do I know my business architect is doing the ‘right’ things?”
Facilitation: Key Ingredients for Success
Anyone who has been in the business world for a while has probably experienced a few painful facilitation sessions, plagued by conversations going in circles and little to nothing being accomplished. With today’s reality of back-to-back and double-booked meetings, the value of participants’ time has never been greater. The good news is that meeting time can be better spent, resulting in quicker decision making and less time to implementation. How? There are two key ingredients to achieve an effective facilitation session – a good facilitator and careful sess
The Value of Relationships
When you grapple with a new idea, where do you start? Most people concentrate on the whole or the parts – either the entity that is the overall idea or the entities that compose it. That we approach ideas in this manner and don’t think about them instead as sets of relationships among components seems to be natural. Relationships, if we get around to them at all, are secondary considerations.
Is SOA really a failure?
I recently came across an article titled “SOA is dead, long live services!” It grabbed my attention (in fact, it is subject of a very lively discussion in the blogosphere), and got me thinking about how SOA has come to reach the “trough of disillusionment” stage. I decided to put some thoughts together, a sort of “a posteriori” analysis of my own experiences. So, why do SOA projects fail? We have the usual litany of suspects: market over-hype, vendor “marketecture”, lack of skilled resources, funding, etc. But that would be too easy, maybe even a cop out.