Two days are rarely the same.
When we start on a project, we adapt our approach based on the needs of our stakeholders and their level of experience with Pega. The first week or so is spent gathering information, building relationships, understanding motivations, and clarifying the key goals and objectives of the project.
Those first few weeks are always full on. We have to assimilate a lot of information from various sources and in many formats and states of completeness. We have to understand the current process(es), the data we will require, and the dynamics at play. We have to plan out what we'll need to do. (and yes, we’re also probably already trying to figure out what the solution will look like!!)
It helps that we have a well-defined Pega Express Methodology, that clearly defines four project stages – Discover, Prepare, Build, and Adopt – and it is a special combination of empathy, skill, experience, and creativity in each of these stages that make us uniquely capable of supporting the rapid delivery of meaningful business outcomes.
And yet the role of the Pega Business Architect is often misunderstood. It is frequently confused with Business Analyst and traditional Business Architect roles. As a result, many fail to fully grasp the importance of the role, and the unique benefits that it brings to the table.
The difference between a Business Architect and a Business Analyst
The industry standard definition of a business analyst is someone who documents an organization’s business processes and makes data-informed recommendations for process improvement through products, services, and software. In practice, however, the role of the business analyst is frequently limited to requirements gathering and documentation. In other words, they function as a kind of integration layer between business and IT, accurately communicating the needs of the business in terms that IT can understand and deliver on. They collect and translate, but are rarely called upon to synthesize or meaningfully contribute to business strategy or the final solution.
The industry standard definition of a business architect, on the other hand, is someone who understands corporate strategy and designs organizational structures, processes, policies, and initiatives designed to advance well-defined business objectives. The business architect is a tactician, but has little to no formal relationship with enterprise IT.
The Pega Business Architect role doesn’t fit within an industry standard definition of either Business Analyst or Business Architect, and that’s why people don’t fully understand what it is that we do. Like business analysts, Pega Business Architects work with organizations, documenting their business, processes or systems, and assessing business models for integration with technology. A Pega Business Architect supports the development of the business capabilities of the enterprise in line with corporate strategy, while also contributing meaningfully to business strategy and plans. A Pega Business Architect is a hybrid role of the industry standard Business Analyst and Business Architect roles. As a result, the value that we bring to the table is more than either traditional role is capable by themselves.
What Pega Business Architects bring to the table
Pega Business Architects don't just do the usual “project” stuff. We also support enablement, taking users and other stakeholders on the Pega journey. Here are a few important things that the Pega Business Architect does that do not fit neatly into either traditional Business Analyst or Business Architect roles:
- Bridge gaps between IT and Business / Operations by accelerating intelligent automation maturity, increasing IT and Business collaboration, and ensuring that Pega is leveraged in the right way alongside any and all other enterprise technologies.
- Support centralization and formalize the housing and reuse of code so the business can build once, maintain assets, and use many times.
- Promote standard methodologies, tools, and education
- Integrate process re-engineering and continuous improvement into projects
- Drive expertise to ensure successful deployment of Pega by eliminating work done in silos without enterprise-wide standards, ensuring the realization of business benefits, and enabling the retention of knowledge and expertise.
- Share documented best practices and standardized governance models
- Improve the experience of all project stakeholders
When I first started working on Pega projects as a client, the Pega Business Architect role didn’t exist. Business worked directly with Pega System Architects. It could be painful for the Business to convey to a technical resource what their requirements were and what a technical solution needed to do operationally. Thanks to the Pega Business Architect role, that pain has now been largely eliminated.
Whether a Pega consultant, a partner, or an in-house resource, the Pega Business Architect has become a key to successful Pega implementations. More than an integration layer, the Business Architect is the glue that binds Business and IT together as they work together over time to achieve common goals in the service of a shared vision.