Here we appreciate two concurrent and conflicting phenomena that are at the root also of API Economy. The first is the so-called Network Effect: the phone has a value that depends on the number of users of the (wired and wireless) phone network, the higher the number of phone owners, the higher the value of the phone; in essence the value of the phone depends on the size of its network. The second is that within network of users compatible goods tend to become commodities and loose value: now there are different phone operators and phone producers, and their network and devices are compatible – I can select AT&T, Sprint, TIM, or whatever other phone operator and I can buy any home phone, and still I can dial a call to anyone in the world. Therefore, the price of the device and of the access to the network has dropped because of the competition.

The essence is that to make profits in the telephony industry, one need to create larger networks of users of dedicated, and possible incompatible devices and services; this is why several ad-on services were created first on the landline phones: remote answering machines, caller IDs, possibility to re-route the phone calls. Also, this is why also different phone plugs were used in several countries: it could sometimes have been the case that a phone plug would cost more than the phone itself! Dealing with mobile phone and still looking at the basic phone services (voice and messages) the situation looks even more interesting: now with a mobile phone there is the possibility of using the data network to make calls and to exchange messages; Skype and WhatsApp are two remarkable example of this. Consequently, the profits made out of phone calls are becoming negligible and suppliers resort either to premium devices (like the iPhone) or to new services, possible creating close and somehow incompatible networks of users.

It is useful to spend a few words more on Skype. Skype is a crystal clear example of all these effects. In it we notice again this constant tension to enlarge the network (to create value), to close the protocol to the competition (to avoid commoditization), and still a move of competing products and system toward integration and interoperability. Skype originally worked only on a few platforms, now it has enlarged its networks to most computing devices, and with the acquisition of Microsoft has also allowed users of complementary products (like Hotmail) to use their credential to access their services; it has also lured the competition also granting users of Facebook to access its services. Clearly, there are competing products that are building up, such as Google Hangout; but it is not (yet) possible to make easily video calls from competing products using the Skype network. Still, it makes profits due to its large user base, not only via marketing and business intelligence, but also by offering premium services that still uses to differentiate itself from the competition.

Facebook and Instagram are also two very clear examples of these processes, as Israel Gat well discusses in his recent blog[1].

The lesson we learn is that at the root of API Economies there are these two diverging effects: network effects and commoditization, and to be successful, we need to create services that “conquer” a large network of users and become indispensable, or, at least, it is hard for the competition to substitute them easily.

Over the past few years, the toy manufacturer Lego rolled out interactive augmented reality (AR) kiosks (a monitor and camera) in a number of retail outlets. (You can view one of the kiosks in action.) When customers hold up a Lego box set to the kiosk’s camera, a 3D image of a completed model built using the box set’s parts appears, anchored to the live video image of the customer holding the box. Rotating the box allows the customer to view the model from different angles.

Now this may seem a fairly trivial example, but it has serious implications. Back in the 1990s, when I first began teaching and writing about e-commerce interface design, I argued that one of the fundamental challenges for Web retail site designers was overcoming what I called the “sensory deprivation gap.” In a physical retail environment, we evaluate products with all our senses. On the Web, we are primarily limited to the visual, thus relying on extremely rich textual content to bridge the gap.

However, even the very simple example of the Lego kiosks alerts us to the fact that something significant is going on. While the Web offered us the ability to reach markets without geographic constraint, it came at the price of sensory reduction. AR technologies represent something new and important, the ability of digital tools to add to the sensory richness of the physical shopping experience in an unprecedented way. The kiosks let customers not just look inside the box butenvision the potential use of the product. Here’s the sixth sense: imagination.

The same principle can be applied to any product. Imagine using a mobile phone to scan the barcode on packaged chicken in a grocery store, getting back five recipes, choosing one, and automatically generating a shopping list for the remaining ingredients. Or, why shouldn’t a pair of pants in a clothing store use AR to help you choose a perfectly matching shirt? The same idea can be applied within your organizations. Imagine scanning a project room’s door to get a real-time update on project status, rather than disrupting the work going on inside by popping in and asking (or adding yet another message to the project manager’s inbox). Or imagine scanning a physical document to drill into the reference material behind it, generating a digital version of the document highlighting changes since the last revision, or calling up contact information and a real-time calendar for the document’s author.

There are many possibilities here, but the central idea remains the same: AR challenges us to think about the information content of objects — and the information relationships between objects — and enables us to leverage this information to create value in new ways.

Already established in the consumer products world, the IoT offers corporations the opportunity to develop new offerings or to reconfigure existing products to collect intelligence. This will drive an increase in big data implementations, cloud, and other emerging technologies as corporations begin to capitalize on this up and coming phenomenon.

Every new trend comes with its share of challenges and implications. For the IoT, these might include breaches in data privacy, security, and governance that occur as more IT platforms are leveraged, generating and transferring more data that is accessed by more and more people (business and consumers) who themselves generate exponentially more data every day simply through using new devices and technologies. The privacy and information security issues involved with the IoT is such a concern that the U.S. Federal Trade Commission (FTC) is holding a public workshop on November 21, 2013 in Washington, D.C. (http://ftc.gov/opa/2013/04/internetthings.shtm) specifically to discuss the issues involved.

An upcoming issue of Cutter IT Journal, with Guest Editor Rebecca Herold, will address the IoT and provide insight on the challenges and possible solutions to ensuring the privacy and security of valuable data assets as the IoT becomes a reality.

Topics to address may include (but are not limited to the following):

* What current and future privacy challenges does the IoT bring to the enterprise?
* How will the IoT impact the way we do business and how can we prepare for it, including planning for associated privacy protection?
* In what ways can security and privacy risks be minimized?
* What types of regulations/governance/practices will be needed to ensure data privacy/security?
* How will corporate networks be affected, and how can corporations prepare for it?
* How can security controls be applied most effectively to mitigate associated privacy risks?
* How do emerging technologies, such as cloud services and big data analytics, impact privacy within the IoT?
* What privacy tradeoffs are necessary, or unavoidable, in order to realize the benefits from the IoT?
* What privacy problems are already occurring within the IoT?
* Will the IoT bring with it an expansive, Orwellian system of constant, ubiquitous surveillance, from which there will be no turning back to individual control of personal privacy?
* How are other countries outside the U.S. taking action to protect privacy within the IoT?
* Is it even possible to truly de-identify personal information within the IoT? Explain how or why not.

SEND US YOUR ARTICLE IDEA by 5 June 2013.

Please respond to the Guest Editor Rebecca Herold, rherold[at]cutter[dot]com with a copy to Christine Generali, cgenerali[at]cutter[dot]com no later than 5 June 2013 and include an extended abstract and a short article outline showing major discussion points.

Accepted articles are due by 8 July 2013.

Editorial Guidelines

The NYPD’s Android-based phones feature an app designed to provide foot-patrol officers with quick, easy access to information assembled from various separate databases. Such sources include databases containing arrest and police incident files, the state’s Department of Motor Vehicles (DMV) records, and parolee and other offender-related information.

As an example, upon approaching an apartment building, officers making their rounds simply enter the address in the app, upon which they are presented with various police/crime-related information for this particular location, including: the names of every resident with a warrant, arrest record, or previous police summons; a list of apartments associated with domestic disturbances that have required police attention; registered gun owners; and photos of every parolee living in the building, in addition to other information.

In short, this smartphone app provides police officers with a veritable wealth of information tailored to help them perform their jobs better. Moreover, the mobile app is fast and intuitive, allowing officers to rapidly view detailed information that cannot be practically obtained from headquarters via their radios (or, for that matter, the laptops in patrol cars) because the information is maintained in multiple different databases and systems that are not integrated. (Apparently, in order to avoid the possibility of having exceptionally high bills from unauthorized calls, the phones do not allow officers to make calls — only to access information.)

Although this project is still undergoing trials, it looks very promising. In effect, the NYPD’s new mobile anti-crime app appears to be dramatically changing the way officers carry out their patrols. And this is the kind of “game-changing” or “killer” mobile enterprise app that companies should now be focusing on developing.

Considering Some Possible Killer Mobile Enterprise Apps

What if your outside sales force or field services staff were equipped with mobile devices and apps similar to the NYPD’s mobile app? Instead of getting access to crime-related information, however, imagine that as sales reps or service technicians approach a client’s facility, their GPS-enabled tablets would automatically serve up selected localized information pertaining to a specific client or customer(s).

In this manner, the sales rep or service technician could instantly see the amount of business the company has done with the customer he or she is scheduled to meet with, view (and interact with) specific orders and service plans, access inventory levels, check shipping dates, and so on.

Such an application would streamline sales and support processes, not to mention enable reps and technicians to appear sharply focused on the customer’s needs, which the client would realize and appreciate. For example, using a tablet, the rep can immediately correct a problem associated with an existing order — even taking advantage of the tablet’s big screen to show and explain to the customer what he or she has done to correct the problem while at the same time emailing an updated order.

It’s easy to see how such a capability could dramatically change how sales and service employees perform their jobs, because it helps optimize the activities by allowing them to carry out various tasks immediately and while in the presence of the customer or client. This can help shorten sales cycles and streamline maintenance activities and other operations while at the same time go a long way toward assuring clients and customers that your company is indeed very much on the ball when it comes to meeting their needs.

Let’s consider another possible mobile enterprise application scenario. Having received an exception alert while commuting to work, a merchandiser or manager, using a mobile app to interact with real-time data, can analyze store or supply chain performance and generate and share a report with colleagues. In this manner, merchandisers and managers are immediately forewarned of any overstock or out-of-stock conditions. Based on this information, they might decide to accelerate or cancel a supplier’s order, allocate additional merchandise to a specific store or plant, promote an item, or put it on clearance — all with just a few taps or swipes on their tablet or phone. Moreover, if such an app were integrated with the company’s enterprise social network (or some other collaboration environment that supports mobile users), it would serve to further help optimize and streamline store or supply chain operations by allowing managers, merchandisers, and other stakeholders easily to share information and collaborate to solve more complex issues as they arise.

Mobile applications like these are now practical, and today we are seeing forward-looking organizations implementing them.

Conclusion

The first wave of mobile enterprise apps primarily focused on adding mobility to existing enterprise applications. Now we are seeing a new wave of enterprise mobile apps designed to streamline and optimize, if not literally change outright, the way employees carry out their jobs. In fact, I would be surprised if we don’t soon witness some innovative company deploy applications that combine enterprise social, mobile, and analytics technologies in a manner that radically alters the way they do business, potentially upsetting their industry. That is the impact I see social, mobile, analytics, and, of course, the cloud (SMAC) having on business in the not-too-distant future. In short, the time is right to start focusing on implementing cutting-edge mobile enterprise apps.

One prediction is that the typical in-house IT department will go up in the value chain, combining its expertise with the domain expertise of the CMO, COO, CFO, etc. IT will no longer be heads-down, technology- and operations-only focused, but will be collaborating with the business side at a higher level than currently being performed to help various departments make sound technology decisions in conjunction with a new breed of service providers.

Another direction IT could take is governing the contractual performance of an Amazon AWS-type service. For example, IT will no longer be fork-lifting a server to (say) replace it with a bigger server. Rather, IT will primarily be developing the contracts with, and supervising the overall performance and service level agreements of those (at, say AWS) who will be doing the actual fork-lifting, or its metaphorical provisioning equivalent.

In other words, the current IT professional might be headed in a few different directions. One might be to remain in a development/operations capacity, another might be in a management/technology/business decision-making role, while another might be in a more consultative capacity.

Or is there another direction IT will take? An upcoming issue of Cutter IT Journal with Guest Editor Israel Gat will provide insight into the future of IT and its new role in the enterprise.

Topics may include (but are not limited to the following):

* Are we moving towards an enterprise IT-as-a-Service model?
* How can IT sustain its competitive edge in the coming years?
* Will IT remain part of a centralized IT department, or be spread out to the various business units?
* In what way(s) is the IT budget likely to change?
* What new technologies/services will determine the role of the IT professional?
* How will the role of the IT manager/developer/programmer change?
* What can an IT professional do now to prepare for the changes ahead?
* Is a shift towards mega data centers preordained?
* Will we see an increase in domestic outsourcing and reshoring?

SEND US YOUR ARTICLE IDEA by 10 May 2013.

Please respond to Christine Generali, cgenerali[at]cutter[dot]com no later than 10 May 2013 and include an extended abstract and a short article outline showing major discussion points.

Accepted articles are due by 14 June 2013.

Editorial Guidelines

Statements like these are pretty common, and it may be a little tricky to see where they’re problematic. However, in both cases the managers started to understand the full set of their problems once we had uncovered the root cause: using project management to manage a product.

There are several ways in which product and project management differ. The most striking difference involves time scope. A project is by definition an endeavor to reach specific goals at a certain point in time with limited resources. It is temporary by nature. The goal of product management is not to reach a certain goal or deadline, but simply to keep the product in the market as long and as profitably as possible with limited starting resources. Before these starting resources are gone, the product should earn enough money to feed itself and grow.

Thus the manager responsible for this product — let’s call her the product owner — has more options than a project manager. She can invest into future profits, she can cross-finance between different clients, and she can deliberately choose to run parts of the product at a loss if that pays off in another area. On the other hand, she has additional obligations: she needs to take care that technical debt does not pile up until it strangles the product, she needs to defend long-term decisions even when their pay-off is in doubt, and she needs to balance the interests of many different stakeholders. These considerations are rarely part of project management, and project management techniques do not support the product owner in making these decisions.

This difference is well known in gaming theory. It is the difference between a finite and an infinite game. A finite game has a fixed set of rules and you play it to reach a goal, usually to win the game. In infinite games, the rules change while you’re playing and the goal is to stay within the game — the longer the better. Soccer, school, and projects are examples of finite games. Marriages, companies, and products are examples of infinite games. Playing finite games successfully requires a different set of strategies and tactics than playing infinite games.

Pumping into a product an additional million-Euro budget for one year is a typical project action. Once the new feature is built, there will be no budget (and no developers) to improve it, to support it, and to keep it alive. Building a platform as a result of “a series of profitable projects” leaves no room for investments, for strategic decisions, or for innovative approaches. Both are tactics to win finite games, but they are rarely helpful to stay within an infinite game because they optimize the short-term at the expense of the long-term.

So why is this pattern so common that we hardly recognize it as malfunction? Often you find the answer in the personal history of managers. Many of them started their careers in project-driven enterprises – which is often a great place to gather a broad spectrum of experiences. In addition, the budgeting and reporting structures of many organizations support quarterly or yearly thinking at the expense of long-term thinking. Finally, the predominant command-control structures stemming from our Tayloristic industry culture discourage the idea of a product owner who has full responsibility for product success.

What are your options? A very fundamental solution is to establish a beyond-budgeting system, but that is typically beyond the scope of even very senior executives. However, understanding the difference between a project culture and a product culture and recognizing the problems a mismatch causes is already an important step you can make just inside your head.

First of all, what do we mean by “marketecture”? With a cynical hat on, some might argue that marketecture is about selling something that you don’t really need. In a Dilbert cartoon from 2009, the Director of Marketecture says that “it is better to seem good than to be good. A misleading benchmark test can accomplish in minutes what years of good engineering can never do.”

In contrast, our aim should be to deliver good enterprise architecture — and to make sure all stakeholders recognize and see that it is good! Here we use the term in this positive sense to describe practical steps that enterprise architects must take in order to properly promote the benefits, outcomes, and achievements delivered by a change to the architecture. Effective communication is key: gain commitment from a diverse range of stakeholders and then keep them on board throughout the evolution and change process of the architecture.

So, in essence, marketecture (sometimes spelled “markitecture”) is a way of presenting the enterprise architecture so that you can promote it in an appealing manner. Typically this view comprises a simplified picture or story that still refers to all key architectural components. It must make sense to both a technical and a nontechnical audience. And it must demonstrate how EA not only supports strategy or requirements but how EA delivers benefits, value, or key outcomes.

Effective Marketecture Requirements

Figure 1 describes the four areas that need to be included in an effective marketecture:

Figure 1 — Marketecture requirements.

1. We need to say a little bit about what we do, as architects, and why we do it. But we shouldn’t get too carried away because it can get boring, esoteric, and irrelevant to our audience. Instead, we need to be selective and say enough to distinguish EA from other disciplines. Think as an architect by using relevant architectural techniques, simplified if necessary, to get your ideas across. Above all, a vital and unique characteristic of EA is the ability to synthesize multiple diverse views.
2. We need to be clear about how we help our customers. All marketecture must be directed to its needs and priorities. Architects must explicitly show how EA supports decision making and promotes effective investment.
3. Marketecture must focus on the delivered benefits, results, value, and outcomes. To do this, we need to build a value model that recognizes the value propositions that matter to our stakeholders.
4. We need to measure and demonstrate our success. We need to succinctly describe the changes we have produced, using metrics that prove things are better.

The two most effective ways to sell your cause are to tell great stories and create compelling pictures. For every EA initiative, there should be a minimum of one really good story — something that can become part of the mythology of the enterprise. And for every EA idea, concept, or transformation that you want to marketect, there should be informal one-page overviews to show the essential components and relationships in the architecture. EA diagrams can be far too complicated and abstruse; don’t fall in that trap. A strong, compelling graphic serves as a great vehicle for getting your ideas across.

Whatever you produce to promote and sell your cause, it must achieve the following three objectives:

• Serve to sell architectural ideas and get commitment.
• Must be easy to understand and explain, serving as a starting point for deeper debate.
• Must be an excellent and useful tool for facilitating discussion and analysis among stakeholders during the design, build, review, and operation of the architecture.

Conclusion

We need to actively marketect EA because (1) the benefits of architecture are mainly long term; (2) we have created a misconception that EA is optional; and (3) the holistic nature of architecture means that there are a very large number of constantly shifting stakeholders.

Marketecture is really nothing more than good communication with people that matter. Three key points to remember within those communications are:

• Think like an architect. Do not use a project or short-term view.
• Maintain an holistic, big-picture overview. Balance all views.
• Create compelling diagrams, stories, and metrics. Use ones that matter to your audience.

The Air Force’s claim of ignorance is curious given that there was a government mandate to provide detailed project status information to the US Department of Defense’s CIO, who in turn was required to review it and then post said information on a government-wide, publicly available IT dashboard along with her personal assessment of the ECSS project’s risk status on a quarterly basis. A quick look at the dashboard shows that the project was rated as only a moderate risk at its demise and had been “closely monitored” by the CIO for the past two years.

A better example of an ineffective IT dashboard for making project decisions would be hard to find.

The ECCS debacle leads to the interesting question of why a reasonably planned IT project using a dashboard would fail. (A “reasonably planned IT project” is defined as one that is technically feasible and has adequate resources of time, money, and people.)

Setting aside project suicides as a possible explanation, there really seem to be only three possibilities. The first is that project management doesn’t want to hear bad news; therefore, bad news doesn’t show up on the dashboard, or if it does, it is ignored.

The second is that project managers don’t understand what the information on the dashboard is telling them. This is always a possibility, especially if the dashboard provides too much information or presents it in a way that is confusing. Still, that’s unlikely for anyone with a minimal amount of professional project management training and a bit of project management experience.

The third is that the IT project dashboard doesn’t provide meaningful information to the manager responsible for the project. (Note that when I say “project manager,” I am including anyone on the project who has decision authority.) I further discuss what I mean by “meaningful information” in the Cutter IT Journal article “A Case for Decision-Focused Dashboards“, but we should remember that a project manager’s sine qua non is to monitor project status and, when required, to make decisions regarding changes or deviations to the project plan. If a project plan were perfect, you wouldn’t need a project manager.

But what is a project plan? A plan is merely a proposed sequence of activities to be carried out over a period of time to achieve some set of feasible objectives, given specific constraints and assumptions (which we call the project’s context). When the project’s activities or context deviate from what is expected — say, the activities were harder to complete than expected, the context changed, or what have you — then it is management’s job to intervene and try to adjust the project plan to achieve the original (or recalibrated) objectives given the changed set of circumstances. (Deviations may also be caused by opportunities to gain increased benefits from the project in less time and/or with less cost.)

Organizations that are successful at adopting and applying agile techniques effectively are going beyond Scrum and Extreme Programming (XP), and adopting a truly disciplined approach. This approach is captured in the Disciplined Agile Delivery (DAD) process decision framework. The framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven and enterprise aware, and provides a foundation from which to scale agile. DAD adopts strategies from Scrum, XP, Agile Modeling, Agile Data, Kanban, DevOps, and many more, providing advice on how to apply these techniques together in an effective manner which reflects the situation faced by the team — one process size does not fit all.

An upcoming issue of Cutter IT Journal with Guest Editor Scott Ambler, will address the benefits, challenges and implications of adopting and applying disciplined agile strategies for enterprise software delivery.

Topics may include (but are not limited to the following) with regard to adopting a disciplined agile approach:

* How can a DAD project be successfully initiated?
* What challenges might an enterprise face in applying a DAD approach?
* What does a full agile delivery lifecycle look like in practice?
* What does it mean to apply a “hybrid agile” approach? e.g. think beyond the “Scrum+XP” box.
* In what situations would DAD not be the optimal approach to software/IT solution delivery?
* How do “enterprise aware” teams work with enterprise architects, reuse engineers, portfolio managers, and other enterprise professionals in practice?
* What cultural roadblocks might hinder the use of DAD and how can they be overcome?
* How are architecture issues addressed on a DAD project?
* How does the role of Product Owner change for large and complex agile projects?
* What roles and team structures are you actually implementing on DAD teams? Do you have business analysts, architects/architecture owners, independent testers? When do you need, or not need, such roles?
* How are you applying disciplined agile strategies to large teams/programmes?
* How are you applying disciplined agile strategies to geographically distributed teams?
* How are you applying disciplined agile strategies in regulatory compliance situations; in CMMI environments; in outsourcing/offshoring situations?

SEND US YOUR ARTICLE IDEA by 1 April 2013.

Please respond to Scott Ambler, sambler[at]cutter[dot]com, with a copy to itjournal[at]cutter[dot]com, no later than 1 April 2013 and include an extended abstract and a short article outline showing major discussion points.

Accepted articles are due by 1 May 2013.

Editorial Guidelines

For the Agilist, (and for anyone who takes interest in knowledge work), Gary cuts to the heart of the matter recounting the following episode:

In 2005, the online chess-playing site Playchess.com hosted what it called a “freestyle” chess tournament in which anyone could compete in teams with other players or computers. Normally, “anti-cheating” algorithms are employed by online sites to prevent, or at least discourage, players from cheating with computer assistance. (I wonder if these detection algorithms, which employ diagnostic analysis of moves and calculate probabilities, are any less “intelligent” than the playing programs they detect.)

Lured by the substantial prize money, several groups of strong grandmasters working with several computers at the same time entered the competition. At first, the results seemed predictable. The teams of human plus machine dominated even the strongest computers. The chess machine Hydra, which is a chess-specific supercomputer like Deep Blue, was no match for a strong human player using a relatively weak laptop. Human strategic guidance combined with the tactical acuity of a computer was overwhelming.

The surprise came at the conclusion of the event. The winner was revealed to be not a grandmaster with a state-of-the-art PC but a pair of amateur American chess players using three computers at the same time. Their skill at manipulating and “coaching” their computers to look very deeply into positions effectively counteracted the superior chess understanding of their grandmaster opponents and the greater computational power of other participants. Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process. [Highlighted by IG].

I might be a little biased as I consider chess and programming to cognitively be twin brothers. Orchestrating a game, if you ask me, is not really different from architecting an application; mastering the intricacies of the Sicilian Defense is similar to getting deep into Java;  recovering from an error is quite similar to fixing a bug; the dreaded time pressure toward the end of the game always evokes in me the dreadful feeling of a (software development) death march; and, of course, chess is incremental – one move at a time. If you asked me whether I am a stronger chess player than developer, or vice versa, I would probably shrug my shoulders and say something like: “I think I am about the same strength in both; as far as I know the two are merely two different applications of the same brain cells of mine.”

If you accept this premise (that playing chess is akin to programming), the aforelisted 2005 tournament, and the conclusions Gary draws with respect to the role of the process in chess playing, are particularly intriguing. Unlike basketball or soccer, Chess had never been considered a team sport. Even in matches between two countries in the Chess Olympics, each game is independent of all other games. The player on the first board will be of the same nationality that the player on the second board is, but other than being played on an adjacent table at precisely the same time, his/her game bears no relationship whatsoever to the game on the second board. To the best of my knowledge, until Gary published his article, the term “process” in chess was always limited to administrative  trivia like determining whether a player in the N-th round will play the white pieces or the black pieces.

Naturally enough, in software development we always aspire to have talented programmers in our product teams. Gary’s analysis indicates that this aspect of team formation might be less important than the process the team uses, its ability to continuously improve,  and the strength of the Scrum Master (or equivalent role).