Thursday, May 17, 2018

Data Modeling for SaaS Projects

This month I was asked to present an introduction to data modeling for a legacy systems team that's preparing for our university's next big SaaS ERP project. This was a great opportunity to think about what's different about data modeling in a SaaS world. The workshop I ended up with was a mix of old and new. If the following topics are of interest to you, the slide deck for the workshop may also be of interest:

First I introduced basic data modeling concepts and levels of data modeling (conceptual, logical, and detailed). I decided to spend nearly all this time on conceptual data models, because I think for most people on a SaaS project team that's where the most important data modeling work happens. It's about building shared understanding of existing data, unmet data needs, and the SaaS product's data model, so those can be reconciled with each other.

Then I showed examples of "reverse engineering" data models from legacy systems. This is a major area of work when a SaaS product replaces legacy systems. At the scale of an ERP, "systems" means one or more legacy core business systems and the related side or "shadow" systems considered to be in scope. The current meaning of the data in the legacy core business system is rarely the same as its original design; different parts of the organization understand that data differently; and the side systems add additional data. A fresh conceptual data model is typically helpful for understanding the as-is.

Next I thought it was important to put data modeling in context. In a significant-size SaaS effort, data modeling is just one of several analysis workstreams including data analysis, process analysis, systems analysis, and managing objectives and requirements. Part of the "art" of running a successful SaaS ERP implementation is making these analyses link up and complement each other -- the whole is greater than the sum of the parts.

Finally, data modeling for SaaS is different in ways that affects individual professionals and teams, leading to changes in careers and team missions. In this part of the workshop I discussed my own experience years ago shifting from data modeling as a developer of databases and applications, to data modeling as a business analyst for a SaaS ERP implementation. For each individual, this is a career choice to set aside some skills (the more technical ones) and learn new ones (the conceptual, people-oriented, and negotiation-based ones). For each legacy systems, team this is an opportunity to do new kinds of work in readiness for the ERP project.

In addition to my own experience this introduction owes much inspiration to the wonderful work of Alec Sharp at Clariteq -- a huge shout out to him and his book, Workflow Modeling: Tools for Process Improvement and Application Development, which contains a great chapter on data modeling in the context of related business analysis.

As always, interested in any comments or questions on this topic!

Thursday, May 10, 2018

Defining a Business Architect Job Description

Last year I had the opportunity to rewrite the job description for my Business Architect role. Since these roles are relatively new in higher education, here's an overview of the thought process.

The descriptions of Business Architect roles that I saw commonly mentioned:
  • Contributing to enterprise strategy
  • Establishing management and governance structures for execution
  • Defining and assessing business capabilities
  • Developing business transformation plans to grow business capabilities
  • Providing guidance to programs or projects
To me, these activities represent a vision for business architecture in an enterprise with mature, well understood architecture practices. To be successful in these activities, the Business Architect would need clear expectations already in place on the part of management at all levels regarding the business architecture function.

What about a business architecture practice that is just starting out? I was the first person (in a 22,000 employee enterprise) to hold a Business Architect title. Therefore my job description needed to be "localized" from a general vision of business architecture to meet the needs of my organization. I found I needed to define:
  • The organization scope of the role
  • The levels the role works at
  • The mode the role mostly works in
  • Its relationship to business analysis

Organization scope

The organization scope of a Business Architect role can vary, ranging from the whole enterprise to an organization within it. This scope describes the expected "reach" of the role and bounds the relationships and sponsorship required for the role to succeed.

In my case the role is located in the Enterprise Architecture program in central IT (a 500 employee organization). The role is focused on business architecture for central IT -- its strategy, portfolio, pipeline, projects, and services. I'll certainly pursue opportunities to contribute in other parts of the university -- especially to strengthen IT-business relationships -- but there aren't formal structures in place for that.

Levels

It's generally acknowledged that a Business Architect's focus may vary across several levels, such as:
  • Organization: Works with senior leadership to establish management and governance structures, processes, and principles
  • Strategy: Works with senior leadership to translate vision into strategy and target capabilities
  • Portfolio: Based on strategy, identifies portfolio gaps and defines needed initiatives or projects
  • Program or project: Works to align program or project objectives with strategies and target capabilities; supports program or project execution
Based on working with my leadership, I see opportunities for my role at all of these levels; I would not exclude any level from my job description. This is largely because my organization scope is already relatively narrow. A Business Architect working on the scope of the whole university, for example, would need to focus on fewer levels.

Mode

From what I've seen, a Business Architect's mode of working can range from more "descriptive" to more "transformative" (or some mix). I see both of these modes represented in the Business Architecture Guild's Business Architecture Body of Knowledge. The following illustrations are from Part I of the BoK, available here in PDF.

Regarding what I call the descriptive mode, the BoK says business architecture provides “an abstract representation of an enterprise and the business ecosystem in which it operates.” Figure 1.1 illustrates what business architecture describes:


Regarding the transformative mode, the BoK says business architecture establishes “a recurring value stream” that provides the “ability to move from a strategic plan through solution deployment.” Figure 1.5 illustrates how business architecture transforms:


For a business architecture practice that is just getting started, both modes are important, but I believe the transformative is dominant. This is because the "channels" by which business architecture analysis could lead to changes don't exist yet; simply describing a current and future state won't create an impetus for change. It's often up to the Business Architect to rally stakeholders, co-lead or lead the change, and sustain it.

Of course, at the same time, the Business Architect has to do descriptive or definitional work. Figure 1.5 in the BoK shows many kinds of descriptive analysis that may be required to support the transformation. It's just that for my leadership, these aren't the deliverables they have in mind; what they have in mind are successful changes. The descriptive work is there to enable the transformative work.

To communicate this with my management, I used this view to show what my role does:


This view relates the Business Architect to a "pipeline" for change. Notice that the role is cast as "support".  There are already people working in this pipeline, doing work that overlaps with my proposed responsibilities. For a business architecture practice that is just getting started, I think it's important to emphasize how the Business Architect will help existing decision-makers and teams work better.

Business analysis

A natural question for a new business architecture practice is, "how is your work different from business analysis?" This is a source of much dispute online. The discussions suggest differences such as:
  • Business architects primarily enable or carry out senior leadership decision-making across portfolios of programs and projects, while business analysts primarily support decision-making within a program or project
  • Business architects consider all stakeholders and work toward enterprise-wide alignment, while business analysts focus on specific stakeholders and alignment within a program or project scope
  • Business architects commonly propose and work to bring about new initiatives or programs, while business analysts mainly work within established program or project goals
  • Business architects are leaders in preparing their organizations to make use of business architecture methods, while business analysts typically work in situations where a business analyst role is already defined
To me, these statements also need to be "localized" to the particular organization. Does your organization have a strong business analysis practice? If so, you probably have senior business analysts whose work overlaps with business architecture (the Business Analysis Body of Knowledge calls it "enterprise analysis"). For example, senior business analysts are probably supporting decision-making at the project or service portfolio level, not just on individual projects. You'll need to negotiate the handoffs between these practitioners and the Business Architect role.

Conversely, if your organization has less established business analysis (fewer practitioners or less scope), then there is an "air gap" that needs to be closed for business architecture to have effective handoffs to business analysis for detailed analysis and execution. This is the situation in my organization (and what I'd expect in most of US higher education).

Therefore, part of my job description is to do business analysis where it's needed to help changes succeed, and another part is to build up the practice of business analysis in the organization. Some ways in which I do the latter include hosting a business analysis community of practice; advising projects on business analysis methods they should apply; offering workshops on business analysis methods; and participating in hiring of business analysts.

Job description

In summary, here's where I landed in applying the above considerations for my organization. The job description states that in general:
Business architects work toward an enterprise in which business capabilities are well-defined and well-aligned with each other and with mission and strategy. Toward this goal, business architects help people work together and make effective decisions on strategies, portfolios, programs, and projects. To do this, business architects apply a wide range of approaches and skills including information-gathering, facilitation of groups, analysis and planning methods, architectural frameworks and models, and leadership methods appropriate to each situation.
The primary job responsibilities that resulted from the above considerations are:
  • Provide business architecture in support of the IT strategy and portfolio management pipeline
    • Support and grow IT strategy, portfolio management, and governance practices through analysis, facilitation, and business architecture methods
    • Propose or facilitate definition of initiatives, programs, portfolios, or organization changes in support of roadmaps
  • Provide business architecture in support of high priority projects
    • Prepare business architecture deliverables (such as functional analysis, process mapping, or capability mapping) to hand off to project teams for detailed business analysis
    • Prepare architectural assessments of systems and information (such as systems landscaping or conceptual data modeling) to hand off to project teams for detailed systems or data analysis
  • Enable other architects and analysts
    • Support and guide project business analysts or architects in the application of enterprise architecture principles and methodologies to improve requirements analysis, project execution, solution development, continuous improvement, or change management
    • Develop training and promote professional development
I hope you found this review of considerations useful, and I welcome your comments!

Friday, October 11, 2013

Leadership and humility

Leadership is a tricky topic. A few years ago, I attended a week-long leadership institute and was struck by the number of quite different definitions of leadership proposed during the week. One reason leadership is hard to define is that it's a balancing act. There's no single trait that makes an effective leader; an effective leader applies a balance of different traits, in different situations, and people lead from different positions.

One of those balancing acts is to combine confidence with humility. Going into a project as an IT professional requires the confidence to propose changes, even in areas that are not my core IT expertise. But it also requires the humility to listen, learn, and involve others in decision-making. What's more, both of those qualities need to be communicated and acted on to build trust with the participants.

What I mean by humility here is not so much the personal virtue of humility (avoiding personal egotism, arrogance, or pride) as it is a set of professional skills. If a person is personally arrogant, they may be personally disliked, and that can be an obstacle. But professionals can learn to listen, seek out information, share knowledge, be responsive, and acknowledge mistakes -- those are acquired skills that can be fostered in a project setting.

I think the combination of confidence and humility is especially important for IT professionals in all kinds of positions because the IT domain overlaps so much with other business domains. This is even more the case when my role is as an architect.

For example, many projects revolve around data. The creation and utilization of business data are business functions, not IT functions. But getting data to the point where it's complete, structured, integrated, and accessible enough to be utilized involves many IT contributions. And along the way, I'll need to recommend changes in non-IT process. This overlap requires IT professionals to have the confidence to lead without knowing everything (sometimes we call that "comfortable with ambiguity"), along with the humility to learn constantly. (Moreover, the overlap may require a reassessment of how the whole IT organization is organized and integrated -- a topic for another day.)

Confidence and humility have to be communicated, and acted on, in a balanced way to build trust between participants. Trust is crucial to any project for many reasons. For example: because it enables the free flow of critical information; because it allows each participant's contributions to be respected and fully utilized; and because it facilitates agreement on goals and measures of success.

If I go into a project communicating only confidence, that isn't enough. At one extreme, suppose I go into a first meeting communicating something like:
Confidence: "No problem, we can fix that for you by implementing solution X. I'll let you know when it's done."
In that style of communication, it actually doesn't matter whether X is the right solution, because I haven't built enough trust to get agreement on whether X is the right solution, or even what the measures of success would be.

If I go into a project communicating only humility, that also isn't enough. Suppose that in a first meeting I mainly conveyed:
Humility: "I don't yet know enough to suggest a solution, and until I learn more I don't want to propose ideas in areas I don't know much about."
In that style, I haven't established myself as an active participant in the project. The participants expect that I'll just offer my own, pre-existing expertise if called upon. That will hold back the project in those areas of overlap between IT and non-IT expertise.

Instead, I want to convey, and act on, a combination of confidence and humility:
Confidence: "From what you've told me, I believe I can create a process in which we come to a solution as a team."
Humility: "To do that, I'll be learning a lot from all of you, sharing what I know, and constantly responding to your feedback (and acknowledging my mistakes) as we work together."
Of course, this isn't just a matter of a couple of sentences in a first meeting. This combination is a set of principles to act on. Whether I earn trust will depend on how I act on these ideas and what contributions I bring to the table.

Have you observed this balance in action, in yourself or in others? What are some other balancing acts that effective leaders negotiate?

Here's some further reading on the idea of leadership and humility: