Gregg Rock interviews George Barlow in April 2022.
GR: In your experience, do you find that organizations understand the value of Business Architecture, or is it a bit of a learning curve?
SL: The standard consulting response is that it depends. Some to, and some don’t. From what I’ve seen, organizations that are rich in workflows and in business roles, such as insurers, claims adjusters, lenders, transportation companies, they tend to have a greater appreciation for what Business Architecture can provide. Now, some of them start with a business reference architecture and tailor it to fit their way of doing business, others develop their own business process models usually, but not always, in a top down fashion.
GR: What do you think the future holds for Business Architecture and what do we have to do to stay in lockstep with the future needs of the organization and the advances we’re seeing in technology?
SL: In one of my articles published on the Business Architecture Institute’s website, I was making the case that the traditional methods that make up the standard Business Architecture canon, they tend to assume a slow changing, relatively predictable, business environment. A business environment where you don’t have major shocks to the system, major external or internal upheavals, essentially an environment that can wait for the business architect to do the architecting.
GR: What originally attracted you to the Business Architecture discipline, and what does Business Architecture mean for you?
SL: Well Gregg, to me gravitating towards Business Architecture has really been a natural evolution. My career started with an education in computer science, followed by a few years of software development, and from there I quickly realized that analyzing and distilling the customers requirements was a lot more interesting than coding the spec. And then, moreover, understanding the why behind the requirements, and that the needs that drove the requirements was even more interesting. Being able to correlate those needs with the customers business mission, business processes, supporting system, and data architecture while having that bird’s eye view of the whole texture of the organization was extremely compelling.
Have I grabbed your attention? Yes, ‘Look How Far I Have Come’ is a song title from the renowned Broadway Musical, Hamilton, but it is also a phrase used by many of us to highlight or showcase their careers and their life progression.
An example perhaps is “I am the CIO now, and this did not happen overnight. Look how far I have come.” In IT, this is used in a similar fashion. From legacy systems, even before, to today—it’s human nature. Look how far we have come, and where we have come from. We were once students getting in line at the University’s computer science dept’ to punch cards for a lousy Fortran IV application, which may have been for a homework or for a midterm/final, and now we drag and drop to put together an app or a UI (a GUI) for iOS or Android. A huge progress, a long journey (not that long ago actually), on our path to excellence, right?
…Sounds obvious, but it is more expensive than you know
Interestingly enough, the true cost of poor process is not in doing the process badly. Clearly there is some cost there, but often it is the knock-on effect that the poor process has on other areas of the company, the downstream of the problem, which is the real cost multiplier.
However, this is rarely calculated. If you have poorly documented and followed processes, you won’t even be able to identify the potential costs downstream—let alone measure them. (Note: processes must be documented AND followed to be valuable). So, like an iceberg, you only see a small part of the problem at surface level. Assuming an iceberg is a problem is looking at an iceberg from the Titanic’s rather than the penguin’s perspective.
Gregg Rock interviews Ed Hunt in November 2021.
GR: Ed, how would you explain business architecture to somebody that’s just coming, brand new, to the space?
EH: That’s a great question. The BA Institute defines business architecture in a very important way: It’s a holistic view of the enterprise, it’s not just the one part, but the whole thing. And that view integrates and aligns capabilities and the BA Institute’s defines capabilities as people, process, tools, and information.
What’s important about business architecture is that it uses models and blueprints of the business to facilitate decision making and help an organization take their strategy from vision, all the way through to execution.
Business architecture also enables the key stakeholders across the organization, at all levels, to align the purpose, mission, vision, strategy, and execution and the models are the tools that make that happen.
What makes a digital transformation successful?
Most organizations have started, or have at least planned, their digital transformation journey [0] [1]. These organizations expect to increase their performance drastically by leveraging digital technologies. However, many of those businesses struggle to meet the high expectations through their digitalization initiatives, and don’t deliver the expected value.
Have You Heard of “Wa-Agile”?
Post-pandemic, there is a clear trend that technology projects are seeing the highest level of approvals. Everyone is looking to not only grow their technological footprints, but to also achieve it in less time and while on a budget. Agile projects are being planned and executed in every organization, which appears to be the best approach to move forward.
Organizations following a waterfall model for technology project deliveries have tried to go Wa-Agile (Waterfall + Agile); another popular term used for Wa-Agile is “Semi-Agile.” This is a step forward to achieve Agile maturity. In organizations where Agile is being used for delivering projects, they are commonly moving towards a 90-days to Go-live approach as opposed to the traditional long-term 180+days delivery approach.
How to Know if a 90-Days to Go-Live Approach is for You?
Editors Note: The BPMInstitute is excited to share this article written by Omer Schechter. This article was originally published on Toptal.com, on June 3, 2020.
Product backlogs are a critical component of product development: Comprised of a prioritized list of features that guides a product from its initial vision to its execution and formal release. By converting high-level concepts into working details, the product backlog facilitates the creation of a product. Let’s take a closer look at the key steps and the core elements of a product backlog and how a product manager is responsible for creating, prioritizing, and maintaining it.
Split the Backlog into Two Lists
When creating a backlog, define its scope, whether it applies to the entire company’s product line, a subset of products, or just a single product—this helps you manage the features.
Everyone starts here.
You're looking for a way to improve your process improvement skills, but you're not sure where to start.
Earning your Business Process Management Specialist (BPMS) Certificate will give you the competitive advantage you need in today's world. Our courses help you deliver faster and makes projects easier.
Your skills will include building hierarchical process models, using tools to analyze and assess process performance, defining critical process metrics, using best practice principles to redesign processes, developing process improvement project plans, building a center of excellence, and establishing process governance.
The BPMS Certificate is the perfect way to show employers that you are serious about business process management. With in-depth knowledge of process improvement and management, you'll be able to take your business career to the next level.
|
Courses
|
|
|
|
Courses
|
|
|
|
Courses |
|
|
Business Architecture
|
|
|
|
Courses
|
|
|
|
Courses |
Certificate
|
|
Courses |
Certificate
|
