Jukka Niiranen

Tag: citizen developer

  • Excel cannot be beaten

    Excel cannot be beaten

    Happy 40th birthday, Microsoft Excel!🎉

    I wish I could start this post by “the first time I used Excel…” But that’s impossible since it feels like Excel has always been there. Not on my very first 386sx PC in the early 90s, no. Back then I was mostly doing games, music, and the occasional pre-internet discussions in different forums (my previous post is all about that). When I started my business studies and when I got my first job roles, though, Excel was just how things got done. A lot of things.

    When I got the chance to visit Redmond for the first time as part of the Microsoft MVP Summit, of course I bought a souvenir from the Microsoft company store that was about Excel. Today, I’m still extremely happy to wear this beautiful shirt:

    The significance of Microsoft Excel and spreadsheet software in general can hardly be overstated. It is truly the nr. 1 business app. Many people could easily do without the other MS Office products, replacing them with Google’s apps or whatever modern tools have emerged in the past couple of decades. But Excel? So many folks would simply hate having to use anything else.

    Why is Excel so unbeatable? Why do so many companies try to fight it nevertheless? Let’s reflect on that.

    Trying to fight Excel

    I started working with customer data analytics and direct marketing at the turn of the millennium. Back in 2000, there was no SaaS. Instead, companies invested in server software and hardware to do things that today’s Excel workbooks with 1 million row limit could easily handle. This scarcity of apps also meant that everything which did not have a dedicated server + client combo in place was done with Excel.

    The Holy Grail of “Customer 360” required a central database for customer information, which meant years/decades of trying to migrate the Excel-based business processes into CRM systems. At the start of such a journey, everyone was quick to agree that “yeah, this thing shouldn’t really be in Excel workbooks”. Once a system was in place, however, the question turned to “can I export this info into Excel?”

    “In the analytics industry there is a standing joke that “Export to Excel” is the most used feature of any analytics software.”

    Hjalmar Gislason: Export to Excel — business software’s most common feature?

    Why do people want to go back to the world of spreadsheet after they have deployed a purpose built business application for the data in question? Because FREEDOM!!!

    Sure, the apps that are designed for specific business processes can give readymade views into the data that you can open with a click. They usually also offer automation that could perform actions like data updates, notifications, summaries, integration, and all sorts of tasks that would be much more laborious when working with spreadsheets.

    It all sounds incredibly useful, especially before you have any such apps in place. The idea of being able to rely on a tool from developers that have already figured out what you’d want the computer to do is just beautiful. Everybody wants to spend less time thinking about “how do I do this” and would rather have “an app for that”. This has given birth to countless SaaS solutions that are simply unbundling Excel spreadsheets into dedicated apps:

    And yet none of the apps can escape the “I wish this worked like Excel” request from the users. Inevitably there will come a time when either the features of the app feel like a constraint that gets in the way – or the users just can’t figure out the intended process of how to do things in this specific, unique application that they’ve not used for this purpose before.

    Why Excel rocks

    For a business applications guy like me, it’s natural to see a process managed with Excel and immediately jump into thinking what data models, interfaces, automations and integrations could be put in place to make everything more efficient. Starting from CRM, the assignments I have been given usually always include the “M” – managing things. Not just for a single PC user but for a group of users, sometimes spanning to thousands of individuals.

    Business apps with a clear separation of the server-side database and logic from the client-side UI are indeed a better way to managing things involving many users. Yet we often forget that it’s not enough to cover 80% of the tasks with built-in features of our slick, modern web apps. The employees who are in charge of end-to-end processes must complete 100% of what their role requires. If our minimum viable product doesn’t have complete coverage, the users need to figure out a way to get the remaining work done.

    That’s where Excel is the hero. It adapts to the needs of the user unlike anything else available to typical information workers. Whereas Word documents are often just digital versions of paper docs, Excel introduces dimensions not found from the physical office tools. Its UI invites the users to model their problem domain in a 2D digital canvas – much like a box of Legos will invite kids (and grown ups) to build abstract plastic versions of real-world things.

    Mr. Alan Cooper, the father of Visual Basic, calls this the fudgability of software. “[Excel is] a terrible program, but it’s powerful, flexible, and it allows its users to work fudgably, adaptably, in real time, while seeing most of what is happening right there on the screen.”

    Sometimes we need rigidity in business processes. We want to have repeatable outcomes that aren’t different based on who is operating the tools, or where & when. Business apps are excellent for facilitating a common way of working. At the same time, we must remember that a significant portion of information work consists of ad-hoc requirements and fuzzy processes adapting to incomplete data.

    That’s when we rely on the humans to understand what should be done. They, in turn, will rely on available tools that allow them to tackle data processing needs without unnecessary limitations. Meaning spreadsheets in most cases. Yeah, I wish more people were able to turn those repeatedly used Excel sheets into low-code solutions with Power Platform tools, yet that’s a bit too much to ask from individual workers most of the time. Most often, Excel is just a better fit.

    LLMs only wish they could be like Excel

    AI is supposedly eating the software world. It certainly is eating all of the available capital (and more) in trying to turn computers that used to be reliable into something that’s… not. The advantages of having the computer understand natural language and being able to respond to any question are of course huge. If only there wasn’t that minor inconvenience that we can’t know if the response is correct or not.

    Microsoft, a.k.a. The Copilot Company, has of course been fearlessly approaching the idea of combining creative large language models with software that is normally used for precise calculations. The result is news headlines like this: Microsoft launches Copilot AI function in Excel, but warns not to use it in ‘any task requiring accuracy or reproducibility’. Okay, cool, I only ever used Excel for fun and games anyway, so no worries about those accuracy gaps…

    The area where creativity and conceptual problem solving could be very useful is in designing how to get from an Excel into an app. I’m optimistic about the LLM-based Maker features accelerating and expanding the possible Power Platform solutions that can be built for varying types of business problems. If we don’t expect AI to work the same way every time, but rather use it as a force multiplier for fudgability, the risks of hallucinations breaking the business processes should be much lower.

    Let’s look at one case where I’d like to see AI replace Excel in my personal life. For 4 years now, I’ve been tracking the expenses related to my car using an Excel workbook. Fuel amount, cost, mileage are an example of what I’ve entered there after every visit to the gas station:

    Many, many times, I’ve thought to myself “I should turn this into an app”. After all, what kind of a Power Platform evangelist would just keep working on an Excel file for years without modernizing the process? Yet whenever I started to think about the details of what should be there to replicate everything my workbook provides (there are other sheets there, too), I realized it’s a heck of a lot of work to achieve parity with what Excel gives me. No rational reason ever existed for me to put in all the work to achieve something that I’d be happier using. It could have been a community demo, sure, but I always had other stuff to work on.

    Now, when we are living in the age of agentic AI, surely it’s about time to replace the Excel? Well, if I could just give that file to an AI tool and make the machine modernize it for me, why not. Last week, when Lovable announced their file uploads feature and claimed “you can now drop files directly into Lovable and turn them into apps and websites”, I decided to try it out. Sure enough, the vibe-coding tool was able to generate a web app from the .xlsx file:

    The only problem? The data is not correct. Like, I only wish my 2019 Ford Focus 1.5 EcoBoost was able to run 100 km on 0.8L… In reality, the React app generated by Lovable was not able to handle the “big data” of around 200+ lines of data in the Excel workbook and instead chose to read only parts of it. The AI chatbot of course will claim this app has “real calculations from your Excel”, but we all should know at this point how LLMs are just manipulation machines that you shouldn’t spend time arguing with.

    I never have to worry if Excel is trying to manipulate me. It may not always understand what I’m trying to do, yet the machine never pretends that it did the work it promised to do while giving out a bogus number instead. The math is not based on vibes. Today, we have LLM-based AI features inside our spreadsheets that are sometimes able to call deterministic tools like Python to do real calculations. But we have no certainty that AI would always resort to such tools when needed, instead of just making shit up.

    That doesn’t stop companies from trying to make AI in Excel work. OpenAI has funded startups like Endex that develop Excel add-ins for injecting LLM magic into spreadsheets. Microsoft is also aiming beyond Excel Copilot with their recent preview launch of Agent Mode in Excel. Could these tools already replace a financial analyst creating Excel workbooks with formulas and business metrics? I decided to give Agent Mode a try on the day it came out:

    You can check out the experience and end results from the video. In short: Excel Agent Mode ain’t necessarily a tool you should yet rely on…

    If you can’t beat them, join them

    Instead of seeing Excel as something that should be replaced, perhaps a better strategy is trying to accept the fact that Excel files will always exist. Because people want to experience the control that Excel gives them, instead of limiting themselves to the GUI prison of your business app. Similarly, they’d prefer if the numbers that get shown to them would be based on verifiable math rather than on-demand hallucinations of “vibe working” tools.

    I’m somewhat biased here because this is the route we have taken when building FinModeler. A SaaS application that helps business founders or financial advisors to create detailed financial models with its simple web-based wizard UI. And then, producing an Excel workbook for you, complete with dynamic formulas that allow you to adjust the model with the tool you know and love.

    It’s not your typical product built on Power Platform. Not simply because of the full-fidelity Excel workbook generator feature. But rather the whole SaaS delivery model of offering a canvas app that requires zero installation differs from the expected way of partners shipping products on Microsoft’s low-code platform. In many ways, this is not how business apps are supposed to work – but we’ve done it anyway!

    Today, anyone can check out how this combination of Power Platform + Excel works in practice by signing up for a free 14d trial of the FinModeler app. There’s a lot more that we can do in future versions of the product, besides just creating extensive Excel workbooks. The fact that the financial model data is stored in a structured Dataverse database is a much better position to build new features than if we’d need to rely on Excel files alone. Still, it’s essential that the users have the possibility to interact with the model that offers them the ultimate level of control and confidence.

    Spreadsheets are forever

    The moral of the story is: it’s not either/or. We are all better off when there are different types of tools available for working with business data and processes. Both structured apps and fudgable spreadsheets serve a clear purpose. Similarly, we have room for both deterministic, reliable software as well as creative and unpredictable AI. Trying to force people into choosing just one tool never works.

    Recent estimates say Excel is used by over a billion human users. In the near future, there will be countless AI agents built that will also try their best to learn how to work with Excel spreadsheets. What I’ve learned is that while you can (and often should) go beyond spreadsheets to evolve and improve your processes, it’s foolish to think that you could replace Excel entirely. Turn it around instead and think of all the data manipulation and calculation features you don’t have to build into your own software, thanks to Excel being there to handle it with ease.

    After 25 years of working professionally in the field of customer data and business applications, I’m proud to once again add a sticker onto my laptop that celebrates the magical powers of Excel:

  • The world beyond apps – my thoughts on AI’s impact

    The world beyond apps – my thoughts on AI’s impact

    This text was written by a human being, not AI – even if some of the images are AI generated.

    Adding such a disclaimer would have sounded ridiculous only a few months ago. Today, many of us are starting to be rightfully sceptical towards online content we come across that touches upon any current hot topic. Is it organic or at least partially machine produced?

    LLMs, large language models, struck earth like a meteorite in the end of 2022 and made some of us question what we really understand about the current capabilities of computers. If you’ve logged in to ChatGPT or signed up for the New Bing version now running on top of OpenAI’s GPT-4 model, you will have certainly experienced a “WTF?!?” moment or a few when seeing the kind of answers they can come up with.

    In this blog post I’ll reflect on the experiences I’ve had with this latest wave of AI capabilities and how I think they potentially will change the business I operate in. Meaning low-code application platforms (LCAP) and in my case the Microsoft stack of tools.

    Why didn’t we see this coming?

    When discussing the AI phenomenon over a pint of craft beer with a colleague of mine a couple of weeks ago, he asked a great question: “why didn’t anyone see this recent AI wave coming?” Indeed, how can people in the tech industry be so surprised about what took place in 2022 on the AI front? Where’s the catch? Is this real or just momentarily hype that will fade away once the next hot topic comes along and takes over our LinkedIn feeds – in the same vein as web3, crypto, metaverse etc.?

    One of my all time favorite phrases is “first gradually, then suddenly”. It applies to pretty much any disruptive change that the world of technology and business encounters. Things like AI don’t just emerge one day and immediately start wrecking havoc. Instead they remain in the “bubbling under” stage for quite some time, then they suddenly erupt.

    ChatGPT has been called the iPhone moment of AI. If we think about the technology that Apple put together to create the original iPhone as a product, key elements like touch screens or downloadable apps were all introduced many years before by the biggest player in the phone business (Nokia). It was not the existence of these technical capabilities that created the perfect storm. It was the way in which they were delivered to the market as a product that made people think: “wow!”

    Creating a web service like chat.openai.com and just casually making it available to the whole world on one day was completely different from having the GPT family of LLM published via the traditional APIs and researcher/developer focused forums. Unlike the iPhone as a physical product, no one needed to purchase anything or make a switch/commitment to experience the potential of generative AI. That’s how you grab the attention of the world in these always-on always-connected days.

    Even alpha geeks like Bill Gates didn’t believe it was going to happen this fast. Tech giants like Google had been sitting on much of the technology needed for building what became ChatGPT, yet they lacked the financial incentive to proceed with it. As a result, in 2023 I’m now using “just Bing it” in a non-ironic way. One year ago I would have given a below 0.1% chance for this being the year of Bing – and today it already clearly is such. Google has access to all the necessary tech to grab the lead, yet the dynamics of their business model (targeting search based ads) is a force very similar to that which took Nokia under once phones became computers. Google, like probably also Nokia, became a victim of their delusions of excellence.

    So, about the original question. No one saw this coming because that’s how disruption always happens. Which leads us to the next topic:

    OMG, they’re coming after us now!

    In the IT consulting business we’re accustomed to the endless talk about change. Everyone wants to change the way how people use technology, and many are surely fantasizing about being able to disrupt existing business models. Very rarely, if ever, do us tech people see ourselves as the target of such disruption. Until now, that is.

    What the recently discovered capabilities of LLM based AI systems have shown already is that a very, very significant share of what us knowledge workers spend our days doing while at work can be handled by computers. It should be a wake-up call to all of us: we have been wasting our wetware brain cycles for reading and writing things that generative AI should be processing instead.

    Shouldn’t we be happy about AI coming and promising to handle the mundane parts of the consulting business that we didn’t really enjoy all that much anyway? While everyone sort of cheers for the virtual assistant that can process our emails, summarize data, generate reports, (very shortly) do basic interactions with CRUD based systems – some might notice that this also sounds like an existential threat. Even Bing knows it:

    Ah. AI skills and bioweapons nicely coexisting in one answer from a service that used to be just a dumb internet search engine a few months ago. Nothing to see here, folks! Move along!

    When I first started to explore this recent leap in AI’s capabilities, I was introduced to Moravec’s paradox. It states that high-level reasoning requires very little computation, while low-level sensorimotor skills require enormous computational resources. In short what this means is: replacing the driver in a car will require a huge amount of computing resources, whereas replacing the office worker sitting next to a computer all day is almost trivial in comparison.

    This is not what most of us have been taught about how technical advancements replace human workers with digital tools. Yet it makes perfect sense when you think about it. The natural selection of evolution has had billions of years to develop the skills we use for observing and operating inside a physical space. Email has existed for only 54 years. We are all really just helpless babies when it comes to processing data, yet we are quite advanced in our abilities needed when diving through the busy streets of a city full of physical objects / actors.

    The arrival of year 2022 level AI skills in the form of LLM was the first time many of us ever needed to take a look in the mirror and say:

    We used to be the ones disrupting the working life of others. Now we are gradually joining the ranks of disruptees. No, I still don’t regret one bit that I chose to pursue a career in the cross section of business and IT. This is a much better position to be in when thinking about what lies ahead and who’s got the possibilities of participating in building something new and exciting.

    Things have always evolved and we’ve seen technological leaps before. I just can’t help thinking that the world in which I grew up to understand what IT is about will now seem incomprehensible to the new generations who’ve yet to discover it.

    Backward never

    As a child, the first time I got the chance to physically interact with a computer was the ABC 80 that my dad bought. Serious computers seemed very complex to use, yet at that time I was young enough to entertain myself simply by typing on the keyboard and pretending to use the computer. Fake it till you make it, right?

    Photo by Frédéric BISSON: Pacman on Atari 800XL at RetroGaming Days IV

    When I got my first personal computer for myself, the Atari 800XL, it supported loading games from a cartridge that you just plugged in. That was the “instant gratification path” of using a computer. I did also start reading the magazines of the time and even typed in a few of the Basic games, transforming the code that was printed on the paper into bits that I typed in via the keyboard. It was interesting, yet it always felt too hard to achieve some tangible results. Code didn’t provide me a way to express myself. It wasn’t until I started creating music on the early PC tracker software that I saw computers as a tool for creativity.

    My kid is now 3 years old. As he’s getting exposed to how technology is used in our daily lives, I’m pretty sure he’ll never see computers as “hard to use”. Now as the natural language interaction pattern will presumably quickly take over most casual usage of smart devices, the concepts of programming or code may remain very distant to him. He’s already happily giving Google Assistant voice commands via a smart speaker in our living room. Why wouldn’t it work for everything by the time he’s old enough to start creating things with computers on his own?

    It goes far beyond the difference between punching keys vs. shouting commands. As of today, Google Assistant is a complete moron compared to ChatGPT. It won’t be that way for long, though. The idea of a computer that understands what you want to achieve without it having been programmed to fulfill that specific request is a shift so profound that such AI capabilities will be infused in every possible smart device. Because otherwise calling them “smart” with the 2021 level of skills would just get the vendors laughed out of our homes and businesses.

    Soon, no one will be given the opportunity to claim that they don’t know how to use computers. There may not be a single visible computer around, but everything around you will be processing data and adjusting itself to the sensors inputs. That’s likely the world in which our children will grow up in, regardless of what we as parents would do. Life without ubiquitous AI may soon be like trying to live without electricity.

    And now to Power Platform.

    Everyone as a developer

    The idea of how the low-code Power tools could eventually democratize the creation of applications is something very close to my heart. The products were introduced roughly a decade ago now. At around 2018 I started talking about the crazy idea of how in the future creating apps would be as commonplace as creating documents already was. I used it as a way to get my point across when talking with colleagues, claiming “every PowerPoint should really be a PowerApp”. I wanted to challenge their traditional idea about apps being something big and expensive created by professionals, insisting that they could also be small, disposable things created by anyone with a computer.

    MS has of course been talking about infusing AI into their product portfolio for a long time already. We’ve seen some neat little demos and product features introduced with what NLP (natural language processing) has been able to do, but in reality it hasn’t had almost any impact on the everyday life of the app/flow/report makers. Sure, AI Builder as a citizen friendly entry point into the world of Azure Cognitive Services has seen some real-life usage, yet it has hardly been a mainstream tool for citizen developers.

    The more powerful next generation AI features have first landed on the pro-code side, under the GitHub Copilot product. These stats from the announcement of the latest GPT-4 based Copilot X version give some indication about the adoption rate. It doesn’t sound like just a marketing gimmick anymore. A fair share of developers out there are probably at least considering taking it into everyday use for the process through which they produce their work output.

    Those of us who come from outside the world of programming and spend our days working with something other than raw programming code could soon be facing the same question: should I let AI do a part of the work for me? As anyone with more extensive experience on Power Platform probably agrees, low-code does not mean low complexity. Working with data, business logic and UI can present quite a cognitive load, even if you are “just point’n’clicking” or writing Power Fx formulas instead of JavaScript or C#.

    If anything, no-code/low-code should become the area in which safe usage of AI generated components would go mainstream a lot faster than in code generated without any productized guardrails around it. In the end it’s still all made of code and it all runs in the Microsoft cloud already (in the case of Power Platform). Training dedicated AI models to serve this well defined playground should be a very doable task for the platform provider. Of course the UX of how app makers interact with the generated results needs to be thought out, as direct manipulation of the generated code wouldn’t be quite ideal.

    If business users will learn to leverage Microsoft 365 Copilot to generate documents for them, how far can we be from the stage where they are also comfortable generating apps and automations in the same way? I believe were are definitely moving into the direction where questioning the abilities of non-programmers to design and develop their own tools isn’t a valid generalization to make anymore. I honestly did not believe we’d get so close to the state of “hey Copilot, turn this PowerPoint into an interactive Power App” being a possible reality this soon.

    This, in turn, will lead us to the question to think about: is this what the world really needs?

    The NoApps future

    In the end, people don’t need apps. In the same way as the record industry was formed around the concept of producing, promoting and selling physical items containing a representation of music created by the artists, our current business applications consulting industry is also focusing on the intermediate output. The actual value delivery is something we must never lose sight of. Else you may find yourself selling plastic discs when the world has decided to jump into streaming audio instead.

    Quicker creation of apps will initially have plenty of demand I’m sure. Besides, it really is a cool demo that you could draw a form design with pen & paper and then have AI generate a digital app’lified version of it (both Microsoft and OpenAI have used this scenario). Yet it’s still just a static data capture form. How many forms can employees or consumers navigate through during their days before getting exhausted with the “there’s an app for everything” experience?

    These UIs for standardized data capture and processing have been needed because our technology couldn’t previously work with anything more fuzzy. Well, we’ve now seen through ChatGPT that it most certainly could. Not only can the AI figure out what us humans mean, regardless of what language we type our text in. It can also figure things out from what anyone else out there in the world has written.

    There’s an interesting demo / research preview of “just some guy” applying GPT-4 to instruct the web browser on what to do. Not just writing out the instructions but actually performing the steps. In the example provided in this TaxyAI project, while on the GitHub website, giving a prompt “protect the main branch” will trigger the AI to do research on what that means, where it should be clicking, and then completing the steps as an RPA style bot:

    I’m not saying this is a tool that would go mainstream. Rather it serves in giving ideas on what the tech giants out there will be creating with their 1000x budgets. The Copilots of tomorrow will not just return a box filled with text that they generated. They’ll probably do the actual work for you, rather than just providing instructions.

    Think about all the process documentation and ad-hoc instructions that has been created inside a medium size enterprise. It will never be realistic to turn each of them into dedicated apps and automations. Yet if we get an AI service that can read these instructions created in human language, turn that into actions for the computer, and then complete the chain of activities to move from the original process input to the final process output – that would be something.

    The concept of “working out loud” by proactively sharing our observations of the world and our accumulated knowledge with the community of colleagues meeting on a digital platform has been a great productivity booster and a source of professional & personal growth for me. Today with ChatGPT or Bing we can gain further benefits by “thinking out loud” with the machine, providing it a sequence of dialogue like prompts. The natural evolution from this could lead towards a world that actually supports “working by thinking”:

    • “Hey Copilot, I spent €50 on a cab ride.”
    • “I can see that you’re in a city where you had previously agreed to visit for a customer project. I’ve grabbed the Uber receipt from your email, filled all the details into our corporate systems and the reimbursement has been deposited back to your bank account.”

    Instead of this sounding like a scene from some flashy “World of Tomorrow” video created by IT companies to sell us boring & expensive tech of today by using a fictious scenario from the year 2060 or something – it doesn’t sound too far off anymore. An AI assistant that understands what we say we want & what others say we should do in order to get it is in theory here today already, in the form of LLM based chatbots.

    We just need to plug it in.

    Endless problems

    Cue the soundtrack from The Terminator. This is exactly how you create Skynet, isn’t it?

    “Defence network computers. New… powerful… hooked into everything, trusted to run it all. They say it got smart, a new order of intelligence”.
    “Skynet saw all humans as a threat; not just the ones on the other side” and “decided our fate in a microsecond: extermination”.

    Michael Biehn as Kyle Reese in The Terminator (1984)

    AI will introduce brand new problems for humanity. Some will be existential (“is there a place for us in the world after AGI arrives?”), others much more mundane. What I’m somewhat worried about is that we’ll be faced with them pretty much all at once in the greater scheme of things. Without the ability to identify what is a serious issue for the whole world, what is merely a speedbump on the road to innovation and business productivity, we’ll be mighty confused.

    The number of things we could be worrying about when it comes to AI is overwhelming already today. Use this list as an example and pick one item if your bag of worries is looking empty:

    • Copyright issues of imitating/borrowing content from original makers without permission.
    • Tech monopolies growing even bigger and stronger than they are today.
    • LLM hallucinations making it impossible for us to know what’s right & wrong.
    • The internet & every media getting flooded with machine generated content.
    • Biased data in the training sets inflicting harm on how minorities get treated.
    • Next generation surveillance society á la Minority Report.

    The challenge I see ahead is that AI may be unlike anything we have ever encountered before. Sci-fi literature and movies have attempted to provide at least some context to the phenomenon, enabling us regular human beings to talk about what’s happening around us by using references from popular culture. Yet where are the AI consultants that will help organizations of all shapes and sizes make sense of this? (I know: just open LinkedIn and everyone is an AI expert there these days. But anyway.)

    The range of reactions to AI that we can expect to encounter when starting to talk about it as just regular technology consultants is probably going to be all over the place. Many organizations will have legitimate legal and compliance concerns that will cause them to choose the “better safe than sorry” approach and put things on hold. Elsewhere, the gains from initial experiments with LLM powered information systems may turn out to be so compelling that AI becomes the next Digital Transformation that must be sprinkled on top of everything the company does.

    I suspect the divide between individuals will be even greater. Just like the low-code tools have enabled the new breed of app makers to stand out from the ranks of ordinary business people and create something few of their colleagues could have ever imagines, the same thing can happen with adoption of AI tools. One’s formal education nor professional background may not be the best criteria to identify those who’ll be able to apply this new technology into solving real life problems.

    If anything, I suspect it will be even more likely that the domain experts, the citizens, will be able to set aside all those “this AI generated code is garbage compared to what a true professional developer could write” complaints and just focus on the end results from using that code instead.

    Good enough is close enough

    We’ve been taught to believe that the world of computing is very binary by nature: it’s either 0 or 1. Computers either behave in a logical, repeatable manner and deliver the exact result they have been instructed to – or they deliver nothing but an error. People trust the computer to be right just as long as someone programmed it the right way.

    LLM’s have flipped these roles around. Now the computer is the creative one, generating an endless list of ideas and content variations, based on the simple prompts given to it by humans. Not instructions like code, as there’s no way to guarantee that the neural network would produce the same output the next time you provide the exact same input. This new generative AI is whimsy and unpredictable, which makes it so much closer to behaving like us humans do.

    If you work in a profession where any part of your output can be presented as text, there’s a high probability you’ve given ChatGPT a go and tested how it performs in producing similar outputs. It’s equally likely that you’ve seen the answers given by the machine to contain plenty of factual errors. “Hah! Nice try, AI, but no matter how much data they feed you, you’re still just a stochastic parrot“.

    We should of course take pride in our craft. Many of us work in an environment where the professionals who can provide the most detailed answers to questions presented to them get the highest amount of respect. We gain trust from others, we build up our own confidence, we “level up” by being knowledgeable in our field and delivering high quality work outputs.

    Are you always right, though? Of course not, we’re all only human.

    Can you apply your expertise to any areas of business? Heck no, the deeper we go on topic Z the less time we have for studying topics A…Y.

    Can you work 24/7/365? Not possible, you know that.

    Communicate in any language? Why are you even asking these th…

    WILL YOU WORK FOR FREE?!?!? Okay, I prefer not to continue this discussion anymore.

    AI doesn’t have to be perfectly accurate to be of extremely high business value to companies. It only needs to be close enough, so that the superpowers it does possess over us living and breathing human beings can be put into use. Yes, it will very often need supervision and intervention from humans at some stage of the process. Yet the biggest financial gains will be achieved wherever the share of human work can be brought down to a minimum. Which means people will be very creative in finding ways to harness the creativity of AI in novel ways.

    AI can always be there for you when needed, whereas a human professional cannot. In my line of business, today the customers are googling for answers and following videos & blog posts to manually repeat the steps on a computer to get their job done. When it gets too tricky or they don’t even know what to search for, Power Platform Advisors can step in and ensure the desired results are achieved. Customers can rely on us, but they need to sacrifice both their time (adjusting to whenever we are available) and money (sorry, we also have to make a living).

    If you can take away all these nasty human constraints, AI will be a sweet enough deal to consider as an option for pretty much anything. People will try it because the barrier is almost non-existent. The tools for creating business solutions will have the Copilot capabilities baked into them, thus promoting them as the first resort. You’d be crazy not to use them.

    What about the possible damages, though? Let’s say that generative AI is right 90% of the time and a human professional gets to 99% accuracy. When your AI built business solution causes big problems for the first time, won’t everyone go back to the good ol’ professionals?

    There will undoubtedly be business models emerging that work a bit like insurance does. Since we can’t be sure that LLM based answers are correct, and we also can’t sue the AI for providing us wrong advise, someone needs to step in and become that middleman. Yes, accidents will happen and someone needs to cover the damages. Now, if your AI based service costs €20/month instead of €200/h and you’ve got a policy that promises to fix whatever issues were caused by unsupervised AI-driven decisions – it can be quite a lucrative model for both parties.

    Bicycle evolved

    Steve Jobs called the computer “a bicycle for the mind.” It is a beautiful, powerful metaphor. In the early 80s, the democratization of computing through the rise of a personal computer that was available for work and personal tasks was presented as a huge leap in the capabilities of an individual. Just like hopping on a bicycle improves man’s efficiency on energy use per kilometer travelled beyond that of any animal in the world, our possibilities for cognitive work rose onto a new level as computers became an everyday tool within our reach.

    AI could lead to something of similar magnitude eventually. Is it just a faster bicycle, though? Did our computers become more powerful or did the tools change in a way that requires a new metaphor? When talking about LLM based tools like ChatGPT specifically, I quite like the analogy of “calculator for words”. It underlines the way in which these new tools of 2023 need to be approached as not the all knowing sources of truth but rather the wizards of words. They are extremely powerful in delivering combinations of words to represent most things us humans use text for (be it communication or code). However, assuming that they understand the world in the way that humans do is a mistake to be avoided when making use of their wizard skills.

    If the electronic calculator was brought into an office where everyone had previously been crunching the numbers with only pen and paper, what would be its impact? A thought exercise like this might help us in understanding why there will be both enthusiasm and scepticism expected as AI capabilities begin to appear in the applications and platforms used in organizations today. And just like what happened to the physical calculator devices, eventually we’ll get a next generation of machines where the ability to perform calculations is just one app among many.

  • Podcast: Understanding Power Platform’s evolution

    Podcast: Understanding Power Platform’s evolution

    Recently I was invited to the Demystifying Enterprise Innovation podcast run by AgilePoint. The podcast host Sharjeel Sohaib is interviewing experts from the field of digital process automation technologies and low-code platforms.

    Our topics covered not only the Microsoft specific technology in Power Platform but also the broader market around low-code/no-code platforms. How are they impacting the lives of citizen developers? What should organizations do to drive the low-code tools adoption? Where is the technology underneath these platforms heading towards?

    This turned out to be quite a comprehensive “state of Power Platform in 2022” type of a discussion. I guess that’s just what tends to happen when someone asks me a question about it. Below is the mind map of what I planned to cover in the podcast episode (click for a bigger image):

    You can listen to the end result on your favorite podcast service – assuming it is either Spotify or Apple. The detailed show notes with a few quotes from me are available on the Transistor.fm page for the Demystifying Enterprise Innovation podcast.

    Notes and thoughts

    In the podcast episode we start by discussing my own journey as a citizen developer from 20 years ago, learning about CRM / marketing automation processes at a large B2C company (Nokia). This path then lead me to different Dynamics CRM consulting roles, and most recently going all-in with Power Platform in 2020.

    Being on the citizen side from day one instead of starting my career in formal IT projects has been undoubtedly one of the key reasons why I’ve found the low-code movement to be so close to heart. To me, the ability to democratize code is a much more worthy goal than just trying to get sales people to enter more information into the CRM database.

    Sure, such business apps may be the “what” but citizen development is the “why”. The way Microsoft has managed to infiltrate the existing toolkits of these citizens by bundling Power Apps and Power Automate into Office 365 is the prime reason why things have moved along so fast in this space. Merging PowerApps with XRM 4 years ago is what allows them to still keep moving fast today, even as more complex enterprise IT requirements now need to be met when the apps originally built by citizen devs are becoming more & more business critical.

    Despite of this move towards enterprise processes, bottom-up innovation is still what excites me the most. Grandiose digital transformation programs with their top-down agendas may have the big funding behind them, yet I believe the net impact from small apps built by citizens motivated to fix practical issues in their daily working lives is going to be greater in total. Teams as a platform is a story that may cause problems for us more experienced MS BizApps practitioners, and still this kind of simplification is definitely needed when you really want to scale low-code in practice.

    Power Platform governance topics are where I spend the majority of my working days on right now. When delivering our Power Platform governance advisory services, I’ve seen how difficult it can be for the IT organization to get a handle on citizen driven apps and automations – at least if no one was there to educate them on how Power Apps & Power Automate administration works in practice.

    This is not so much a challenge of the technology not being available. Rather it is the new roles and alignment of IT alongside the citizen developers that poses the biggest barrier for companies to feel safe enough to fully embrace what this corner of the MS cloud can offer them. The same gradual increase in maturity that has happened with Office 365, Azure, and also Power BI from the “power family” – all of it seems inevitable for Microsoft’s low-code products, too.

    This is why we’re now seeing less new maker focused features right now and a bigger push for admin & governance capabilities in Power Platform. The next big target for MS is in formalizing the fusion development story for low-code, to get the professional developers on board this new way how customer organizations address the growing demand for digital solutions that can’t all be met with custom code alone.

    The ISV opportunity in Power Platform has not yet been a true focus area for Microsoft. Their emphasis has been on the internal transformation of organizations via citizen developer solutions. Yet many MS partners are naturally interested in the huge opportunity of the low-code movement. They’d love to become a part of this new ecosystem where the number of low-code developers is growing by 40% every year. However, there’s a lot of work ahead before the mainstream wave of ISVs could be onboarded to Power Platform, both from commercial and technical perspective.

    We can’t just take the good ol’ Dynamics business model and apply it to Power Apps since the platform is designed to empower bottom-up innovation distributed all across the organization (who’s gonna do the top-down purchase decision on your project?). Neither can we make the Office style assumption that all these tools would be common to all information workers (justifying the premium licenses requires stepping outside the generic productivity story and quantifying the value from business specific processes). Experience from the other MS clouds is definitely a major advantage from an ecosystem insights perspective. At the same time, if you just sprinkle a bit of Power Platform technologies on top of your existing business model and projects, you can’t expect to see any radical growth or shift in how your customers are engaging with you.

    At Forward Forever we’ve been lucky to get the chance to educate several MS partner companies on the practicalities of developing apps for Power Platform in 1:1 coaching sessions over the past two years. It has affirmed our belief that this low-code movement is an infinite game where we aren’t competing against other players. There’s no sense in trying to be the winners once the final whistle blows. Rather we should do our best to keep the game going, helping the whole league around us to grow and build an audience (even a fan base) who wants to see us succeed.

    There are no winners or losers in an infinite game; there is only ahead and behind.

    Simon Sinek

    In addition to advising customers and partners on how to succeed with Power Platform, we’ve also invested resources into building products on top of it. Our offering in this field has recently reached a point where our Sustainability Action Pack is now listed on Microsoft AppSource for everyone to see. It’s a solution template that provides tools to drive environmental actions, make progress transparent and help organizations reach their social, environmental and climate targets (see SECAP).

    Power Pages, Power Apps, Power Automate, Power BI – the whole MS low-code stack is being used when we’ve delivered the solution to municipalities in Finland. The big difference compared to Azure based applications, for example, is that the end product truly runs on the customer’s platform. Modifying and extending our Sustainability Action Pack functionality can be done by business users – as long as they’ve got the willingness to learn how Power Platform works.

    This might have been just marketing talk a decade ago. Today the reality is that the persons who are willing and able to use these low-code tools to shape your business applications are likely to be among your most valuable employees. They probably haven’t been hired for this exact role, yet the organization should acknowledge the positive impact that they’re able to achieve by adopting Power Platform tools and thus adapting your tools to deliver better business outcomes. Otherwise they may quickly find a new place to work where such evangelism is appreciated.

    From the outside, as a consultant/advisor, we can only show you the direction to take. The real adoption journey for low-code relies on empowering internal personnel to build new things that create business value. Ownership of your own tools is the biggest difference in mindset when it comes to the traditional Dynamics business applications versus the new breed of Power Platform solutions. This is the revolution in low-code – the technology part is just evolution.

    For more of my thoughts on Microsoft Power Platform evolution / low-code revolution, go and check out the podcast episode:

    Demystifying Enterprise Innovation podcast
  • Democratizing code

    Democratizing code

    Throughout my whole professional career, I’ve worked with technology that caters to information workers. Sometimes I’ve been the power user of these tools myself, then a manager responsible for defining the details how these systems should work. For the past decade I’ve been the guy who actually puts the technology pieces together to deliver that system.

    I have never written code in traditional programming languages for a customer project. Sure, I’ve done plenty of work that isn’t accomplished via point & click GUIs, but none of it resembles what the Wikipedia definition of computer programming says. In short: I don’t code.

    Every year it feels like I’m sinking deeper and deeper into the technology domain of Microsoft business applications, and at the same time it’s less & less likely that I’d start writing code for a living. The rise of low-code development platforms (LCDP / LCAP) like the Microsoft Power Platform means that there are more & more people like me out there. Citizen developers are taking over many application development tasks but they don’t do what traditional programmers used to do.

    The impact from this paradigm shift is potentially massive. Computer programming isn’t going away nor decreasing as a professional activity. However, application development as a task is being separated from the domain of programming. The output of what “code” used to create is therefore being democratized:

    Democratization of technology refers to the process by which access to technology rapidly continues to become more accessible to more people.

    Wikipedia: Democratization of technology

    In this article I want to write down a few observations and thoughts on this topic, which I’ll hopefully get to drill deeper into in future writings.

    From code-first to low-code

    Things have moved along surprisingly fast. Just three years ago there was a small debate in the Dynamics 365 community on whether all functional consultants should know how to write code. Neil Benson’s excellent article called “Three forbidden words: I don’t code” popped up in my Timehop stream a while ago to remind me about this. (I must stress that despite of the title, Neil actually argues against the need for every consultant in the project team to write code.)

    https://twitter.com/customery/status/981128432384962561

    Today in 2021, this whole question on whether every IT worker should invest time and effort in learning a “real” programming language felt to me like it must have been from a decade ago. To put things into perspective, we have to keep in mind that this original debate took place in 2018 , at a time when the fusion of Microsoft Dynamics 365 and PowerApps (the “no space” era) had just been announced. MS had only just begun the process of throwing BizApps consultants and citizen developers into the same pool of technology. It was a very different world still.

    Fast forward to 2021. If you look at what the Power Platform community has been debating about recently, I’ve seen a lot of concern from people with software development background & skills. “Isn’t Microsoft valuing coders anymore?” is a question that can rightfully be asked when looking at the common theme of marketing messaging coming from Redmond. It’s a stark difference to just 3 years ago for sure.

    Already earlier, many customers who have previously been burned by problematic CRM implementations full of custom code have begun expressing their preferences in subsequent projects. “Avoid code based extensions and leverage OoB configuration options wherever possible” has not been an uncommon requirement to hear from them.

    Now when Microsoft is advertising how powerful the low-code options can be, it’s going to be even harder to suggest code-first solutions to customers. At least you need a clear justification for why custom code is necessary. This can have unfortunate side effects, too, where the avoidance of coding leads to an even harder to maintain maze of configuration spaghetti. Different cooks, same dish.

    Excel is eating the world

    Power Fx has received a lot of attention based on only the initial announcement of what Microsoft plans to do with this new low-code programming language. I’ve previously analyzed the broader role of Power Fx as well as reflected on how Dynamics 365 professionals might approach it.

    I’m not so sure that it’s wise for MS to go out and shout to the world at this point that “Power Fx is the world’s most used programming language”. Also, I wouldn’t personally say that my Excel skills have gotten me that far in creating formulas for Power Apps Canvas apps. It takes a lot of tutorials and browsing through the formula reference to get into grips with Power Fx.

    Yet there are unquestionable benefits from using the “Think Excel” mantra as the backbone for developing this new programming language for the low-code era. Not just for sharing the same function names, but rather for ensuring the focus of Power Fx remains squarely on the power users that can make Excel sing. Not those wannabe programmers who eventually want to move from the safe sandbox of Power Fx into something without the training wheels. Of course one still might need to have the programmer’s mental model for producing complex apps with Power Fx regardless:

    We need to keep in mind that Power Fx is not aimed at the audience who writes code for a living. Microsoft is not expecting that developers with skills in other programming languages would switch over to Power Fx. Rather the purpose of (eventually) open sourcing the details of the language implementation would appear to be in enabling other parties outside Microsoft to adopt Power Fx for their products.

    Despite the ubiquitous role of Excel in the business world, we should not assume this spreadsheet software to be the only place where future app developer generations will gain their experience from. Gaming platforms like Minecraft or Roblox with their big focus on user generated content could be considered equally important sources from where the inspiration to become a digital maker is first put into the mind of an individual.

    After all, being a guru in Excel formulas isn’t perhaps the strongest indicator of being a potential business app maker. The no-code generation is less likely to dive deep on a single tool, rather they are fearless in combining new services together on the fly to reach the outcome that they need. Separating this ability to grasp new technical tools from the ability to write algorithms in traditional software code is perhaps where the true democratization will take place.

    Professionals vs. Citizens

    The terms we use for grouping people into different teams in the current articles that cover the phenomena of low-code and business applications are somewhat problematic. On one side we have the “classic” developers under the banner that says Professional Developers, while the other crowd represents the “modern” way of creating apps and has been given the Citizen Developers banner.

    “And now, ladies & gentlemen, LET’S GET READY TO RUMBLE!!!!”

    That is exactly how we should NOT depict the situation. There are no winners and losers in this game. We haven’t invented a silver bullet that solves all business problems. There’s no eternal glory to be found from being “all code” or “no code” in everything you build. Yet it’s obvious that we’re not talking about a homogeneous group of developers here. Some of the platforms and tools used may be shared across, but the roles remain distinct.

    The amount of low-code business applications that organizations of all sizes in every industry will soon have in their hands means that we’ll see a growing number of employees working 100% on these. If low-code becomes your full-time job, you’re not just a citizen or a hobbyist. You’re a professional working with advanced technologies and complex processes. The only thing that separates you from the “classic” definition of a Professional Developer is that you don’t write much code (aside from things like Power Fx).

    Microsoft seems to have already reduced their use of the Citizen Developer term. This doesn’t necessarily mean that it would not continue to exist in the discussion, as the idea of anyone being empowered to create apps still is a powerful way to get the message across. It’s more likely that the terms used to describe the different roles within the “fusion teams” that deliver Power Platform based solutions will need to be adjusted.

    When a business professional starts handling more and more technical tasks in the app delivery process, I don’t think this makes him/her a Pro Dev nor a Citizen Dev. It is the area in which I personally operate and yet I can put a label on it. Luckily it doesn’t make my work any less valuable. I’ve always lived as the secret agent between business & IT, so I can easily remain to be that mysterious Agent X. As the army of these agents grows, though, they’ll become a lot less secret with their presence within organizations.

    Are they simply “Makers”? Time will tell.

    Where democratization may lead us

    I think what’s happening today with software resembles something that has previously happened with media. Two decades ago we saw the Web 2.0 phenomenon that moved the online world forward from a static web towards a social web. The elements and the actors aren’t all that different from what the move from code-first to low-code apps is dealing with.

    Content creation exploded when the ordinary people (citizens) were given tools and channels to shift from just being content consumers to the new role of content creators and publishers. That was a huge transfer of power. For me personally, my decision to start this blog back in 2008 and to become an active participant in the Twitter community around Microsoft business solutions have been far more powerful decisions than anything I’ve ever had the chance to make at my actual day job.

    If the traditional media was run by Professional Journalists then what emerged from the social web & social media revolution might as well be called Citizen Journalists. No longer was there any formal training nor editorial processes required for getting your content out there. It had a profound impact on our society as a whole, in both good and bad. The forming of new citizen driven communities around topics like business apps is a very mild example on that scale, but it’s where I’ve been able to observe the phenomenon in the closest possible detail.

    What happened with human communication in the Social Web revolution could very well happen with human-to-computer communication in the next uprising. On a high level, I can’t actually see that many differences between what WordPress did to words and what Power Platform aims to do to apps. Different context yet the same underlying dynamics of how the traditional top-down model is replaced with a bottom-up approach.

    One specific insight that could be drawn from this analogy between the social web and low-code movement is the ratio between different user roles in each. Even if anyone could technically start a blog these days, relatively few people have done it (and even fewer have managed to stick to it over the years). Most are merely content consumers, and some are active in commenting or sharing content.

    It’s very likely that we’ll see a similar distribution when it comes to low-code apps in the business world. Only a small share of those with access to the tools will ever become consistent app makers – and that’s perfectly fine. It’ll still be big enough figures to disrupt the traditional usage of code.

    Opportunities and threats of low-code

    Just like the rise of Facebook or Twitter didn’t solve every problem related to media, we aren’t going to reach the promised land of digital transformation merely through low-code application platforms. Many of the arguments heard from Professional Developers on why the actions of Citizen Developers will create a flood of new problems are in fact well founded concerns.

    Change management and version control don’t suddenly become a non-issue. Application lifecycle management (ALM) isn’t automatically taken care of. Architecture design and documentation can’t be skipped. Just by moving certain parts of the software development lifecycle from code based tools to graphical configuration tools and formulas like Power Fx we’re not magically making all the other parts irrelevant.

    Some of the problems encountered with traditional business application delivery will only be amplified by the low-code model. As the volume of apps grows, as we have more parties involved in their development process, as the backgrounds of these individuals will be more varied – we’ll run into scalability challenges for sure.

    This just highlights the need for new innovation. Reaching into the existing ProDev toolbox isn’t likely to be the answer – just like you couldn’t adopt the practices from a traditional media newsroom and apply those into social media platforms.

    Be it the creation of content or apps, any model of manual governance and control that relies on A) the creators to follow specific rules and policies, and B) human editors/gatekeepers to enforce them, isn’t going to scale very far. Algorithms must be put into use. AI needs to be given the opportunity to help us in everything that goes into developing and maintaining great business apps.

    Can’t put the genie back in the bottle

    It’s time to accept the fact that this thing won’t go away. What low-code represents is not any specific service or tool that today allows you to do A, B and C – but not yet D, let alone E. It’s all about the journey – how to move closer and closer to Z, one step at a time.

    Success is not defined by whether you would ever reach Z without writing a line of code. What low-code platforms aim to do instead is to keep grabbing the low hanging fruits of app development, one by one. Focusing solely on the “what’s missing compared to code-first” aspect is therefore not very beneficial in understanding the actual value that has been derived from different generations of low-code solutions, be it RAD tools or application platforms like XRM.

    Sure, there aren’t many new apps being built on top of MS Access or Lotus Notes anymore (hopefully). Does that prove it was a bad idea to build any of them in the first place? Of course it doesn’t. These tools may have only been good at A or B back in their days, yet there was significant business value to be gained for getting the crude apps out there to the users who needed to manage digital information via them. Besides, even if you built a “proper” app via custom code in the golden era of Access or Notes, you would have likely needed to re-build that solution a few times anyway to stay relevant with modern client technology and new business requirements.

    The evolution of software keeps pushing us towards higher levels of abstraction. It would be strange to think that the direction could ever turn and we’d see a large scale return to artisan software being carefully crafted by coding every line by hand, reducing the use of libraries and APIs that offer shortcuts to those soulless programmers that just want to meet customer requirements quick & easy.

    Early days still

    I’ve had a great opportunity to dive deeper into the concept of low-code during the past year, ever since we founded a company that focuses 100% on Microsoft Power Platform based solutions. One key insights from all my investigation work has been that we’re not yet very close in finding common ground on what low-code actually means. Neither the vendors, tech media, consultants nor customers seem to have a clear understanding on where to position low-code in the greater IT scheme.

    Academic research on topics like end-user development (EUD) / end-user programming (EUP) seems to have mostly stopped almost 10 years ago already – before the invention of the term “low-code”. One study from December 2019 specifically calls out the lack of recent research activity “There are very few publications related to low-code aspects and they are from the last two years, demonstrating its emerging trend.”

    Since it currently appears to be mostly the vendors like Microsoft, OutSystems or Mendix who are pushing forward their agenda, with help from analysts like Forrester in building up the hype, it’s hard to know what percentage of the low-code and citizen developer stories out there are based on facts. Sure, projections like these make it sound like it’s already an amazing success story:

    • Gartner forecasts worldwide low-code development technologies market to grow 23% in 2021.
    • Forrester analysts estimate 75% of all enterprise software will be built with low-code technology this coming year 2021.

    It must be great for anyone investing in low-code to be able to present such growth percentages, to prove they’re betting on a winning horse. Still, I feel like we’re only starting to write the greater story behind all this exciting technology. Democratizing the tools through which our digital world is built one app or one automation at a time – that’s gonna be a bigger deal than just the amount of VC money being pumped into no-code/low-code startups.

    At the end, it’s not even about which tools and platforms will win. Looking at both the investments as well as progress made by Microsoft into/with Power Platform, I have very little doubt that they will be taking low-code into mainstream for real. What’s the truly interesting part is thinking about all the ways in which this may change the business user behaviour, the role of IT departments, the market dynamics for professional services – basically everything around the low-code platforms.

    If that’s something you’re also interested in talking about in more detail, perhaps you’d want to reach out to us at Forward Forever. Or if you feel like there’s something I’m missing in the above thoughts around the democratization of code, I’d sure appreaciate any comments in the box below.

  • ALM for low-code: are we there yet?

    ALM for low-code: are we there yet?

    Application Lifecycle Management, ALM, is a topic rarely covered in the mainstream pitch for how low-code/no-code solutions are transforming app development practices. This is understandable, since the initial time-to-value, from an identified business need to a working application (or at least a functioning prototype of one) is where the major difference to the traditional software development initiatives are easiest to demonstrate. It’s the “five minutes to WOW” effect that gets most of the attention.

    Relying on configuration and formulas over custom code does promise also a lower maintenance overhead for the post go-live phase where the apps are used and evolved gradually to remain in line with the business requirements. There is less to worry about the potential impact of changes in each of the underlying components that keep the app running when you’re subscribing to a service like Power Platform that aims to abstract away many of the moving pieces in Azure and other related cloud services.

    You shouldn’t assume life to be completely worry free, though. If you don’t plan ahead on what type of work is needed after the creation of your low-code app, then a nasty surprise may lie ahead for someone, somewhere, at the most inconvenient time. In the worst case your organization has become reliant on an app that no one owns & no one knows how it works, only to realize that your processes have already stopped due to errors caused by a change either inside or outside the system. Updates to the cloud components or changes in APIs used via Connectors, for example. A slower yet equally frustrating problem can arise from identifying a future change you’d really need to implement for the app in question, yet you don’t have the means to make that happen in practice.

    The rise of low-code application development and the forecasted arrival of 500 million new apps in the next 5 years is making IT organizations very aware of the need for setting up governance models to address this new reality. Having baseline knowledge of what apps are created, by whom, for which audience, for what purpose, through what technologies, on what data sources etc. is often the discussion that needs to be done first to analyze the current situation. A great tool for facilitating this is the Power Platform Center of Excellence (CoE) Starter Kit, which gives you an overview of the big picture for Power Apps and Flows in your tenant. To go deeper and actually manage the lifecycle of an individual (potentially business critical) application, we need to start discussing ALM.

    What is this ALM thing anyway?

    Microsoft has published fresh new documentation on ALM with Power Platform that could be viewed as a similar Starter Kit for this topic as the aforementioned CoE. It briefly covers the high level summary of what ALM means:

    ALM is the lifecycle management of applications, which includes governance, development, and maintenance. Moreover, it includes these disciplines: requirements management, software architecture, development, testing, maintenance, change management, continuous integration, project management, deployment, and release management.

    A very broad concept then. What I like most about this intro chapter is the definition of the goal of ALM: “driving efficiency through predictable and repeatable software delivery”. That’s the essence right there. Anything that reduces the differences between how individual app makers / developers perform common tasks within the whole lifecycle of a specific business application will improve the state of your ALM practices. Those with a software development background may immediately venture into thinking about various DevOps methods and tools at this point, whereas I’m always most concerned about how the business can get a grip of what exactly is happening to their applications over time. Who built what, based on which specification, when was it deployed & where to, how were the changes documented, what impact did it have on others systems, how were users educated on the new features, and so on.

    Microsoft’s ALM guidance is mostly revolving around the technical level specific to Power Platform, meaning how solutions and environments should be used. If you haven’t heard it before, then the solution framework that was born in 2010 for the XRM era has been actively expanded to cover more & more areas that are not a part of the Dynamics 365 Customer Engagement on-premises server. Canvas apps, Flows, AI Builder models, Power Virtual Agent chatbos, Export to Data Lake configs, pretty much everything in the Power Platform is now manifested as solution component. More is on the way, based on how Matt Barbour has stated things like Power BI and integration services being “on the radar” for the Power Platform solution system.

    The expanding technical capabilities and scope of components shipped via solutions is of course great news. However, as we are now talking about the platform for every developer, not just pro devs, my number one question about Power Platform ALM is not “will it scale up to new products and features” but rather “will it scale down to new types of apps that don’t follow the lifecycle of a CRM system?” So, there’s two dimensions I feel will be critical for the ALM story to succeed: 1) unifying the mechanisms to manage configuration & code across the different app teams within MS Business Applications Group, and 2) democratizing healthy ALM practices by making them accessible to citizen developers. The first one is well underway with the solutionization of everything, but how about the second one?

    Managing your “source low-code”

    The fundamental challenge with why ALM tools aren’t already a part of every Power Apps maker’s or Dynamics 365 customizer’s core workflow is that they don’t exist within the context where these people do their work. This audience doesn’t need Visual Studio for anything, nor would there be anything familiar with the terminology used by version control systems like Git. This is alien technology from Planet Developer, which the no-code app makers would have to learn specifically for the purpose of managing how their configuration deliverables are moved from one environment to another. Compare that to the “export solution as .zip” / “import solution .zip” actions availble in the Power Apps Maker GUI that gets the job done for them. Many of these app makers surely understand the value that a formal deployment process and solution versioning could offer, but the barrier has been much too high for them to make that leap.

    There have been tools for pro-code developers working with XRM solutions for many years already, some provided by MS and many built by the community. Today there are official Microsoft Power Platform Build Tools available for Azure DevOps, which offer readymade tasks like solution export, import, unpack, pack, publish, with more features to come. Rather than tweaking PowerShell scripts, it would seem like there’s a way to visually configure the cloud to do some ALM magic for our low-code apps. Sure, this is not within Power Apps directly, but could this be considered just another admin portal that the citizen developers might learn to navigate?

    Get the Microsoft Power Platform Build Tools

    Setting up an Azure DevOps pipeline that pulls solutions from your dev environment, commits them into a repository for version control and then deploys that same solution to test or prod still isn’t exactly a next-next-next process. However, following a Power Platform specific tutorial, even a non-developer like me can get this up & running in a few hours. MVP Nick Doelman has written exactly what I needed, so if you’re interested in building your very first ALM pipeline, I recommend you to try this out:

    Simple ALM for Power Apps/Dynamics 365 Projects Revisited – Power Apps Build Tools edition

    Combining this with a recent update to the Power Apps Build Tools that also introduced support for MFA protected environments (meaning you can log in with an Application User identity), I was able to get our company’s “CRM” solution’s customization changes from from Dev to GitHub and Dev to Prod. Here’s what it looks like now when adding a new field on the accout entity:

    “Woo-hoo, we now have proper ALM in place!” Well, not quite. All that we really achieved with this was the possiblity of doing it “right”, meaning there are DevOps pipelines that could be used for handling configuration changes automatically instead of manually by individual low-code developers. Until I actually go and remove all Power Platform service admin roles from my colleagues, anyone of them could still go and mess up the production customizations directly. So, proper ALM is only partially about the tooling and automation – you still need to the exact same thing as without DevOps, meaning defining the processes and agreeing on the practices for how the business applications are managed.

    Regardless of this, it does makes perfect sense for low-code app development projects to evaluate if they would get benefits from leveraging automation tools like Azure DevOps. You’ll need to have the solution configuration stored somewhere anyway, so why not put it in a version control system that’s designed for “real code” and gain access to things like viewing the changes of individual solution components – rather than just dumping the files on OneDrive/SharePoint. Who knows, taking that step might even unlock further opportunities to automate and harmonize your application management processes.

    We should keep in mind that automation is a double-edged sword. In theory it can save you a lot of time, yet in practice it may often turn into an additional time sink of its own. The legendary webcomic XKCD beautifully illustrated this dilemma of Automation, which I think is especially true here in the ALM discussion. The tasks that you’re trying to automate need to happen on a frequent enough basis for a long enough time before you could achieve a positive ROI from investing in setting up your pipelines. A single citizen developer building a one-off app may not yet meet that threshold, so preferably in your automation scenario there should be a team of developers who will do several planned releases for the app in question.

    ALM for a team of low-code developers

    Microsoft likes to promote the stories of Power Apps Champions who have managed to make digital transformation a reality for their organizations by building low-code apps that would have earlier required a team of software developers. This marketing approach higlights the role of an individual hero, but from an ALM perspective the dependency to any individual person’s heroic actions and secret knowledge is rather a problem that should be solved. Once that initial app idea and first PoC starts turning into something business critical, you should have a team in place that can ensure its continuity.

    This team may not resemble your typical software development team. Yes, it’s quite likely that there will also be people with programming skills either working in the team or closely with it, but the primary competence on the technology side for this team is in assembling the features and components of the chose application platform into solutions that solve a wide variety of business problems. They are less likely to be all working with the single code base of a large application, doing pull requests, commits and all that Git jazz, simply because a fair share of Power Apps aren’t going to be built that way at all.

    If you look at Power Apps Canvas apps today, they are essentially a document made of JSON that cannot be simultaneously worked on by multiple developers. This is very different from a traditional app project on the Model-driven side (let’s say in a CRM context) where one person could be building the customer data management features while another team member is working on products and order management. All with their own dedicated entities, having so little overlap that simultaneous work within the same dev environment is often doable. Even though Components promise to offer a more modular way to build capabilities for the Canvas world (and Model, too), I suspect that the client side experience of a single app will typically remain a “one maker show” in the near future.

    Sharing elements and patterns across different apps built and managed by the team is, on the other hand, in a much greater role in the low-code approach. Here components, template apps and other reusable pieces of configuration can be of high value. Power Apps began its journey as a citizen-first app creation experience yet is gradually accumulating more of these features that mean every app doesn’t have to be a unique project. We’re getting more & more possibilities to see beyond the Maker GUI, like “peek code” in a Flow or use Monitor to debug Canvas app formulas. However, based on what Microsoft representatives have publicly said, it doesn’t sound likely that these low-code tools would evolve into allowing app makers to directly manipulate the configuration files in VS Code, for example. There are community tools like CanvasAppPackager from MVP Daryl LaBar that will help app developers understand complex Canvas apps, but these are NOT meant for building or modifying apps.

    Even in Model-driven apps the list of supported modifications for customizations.xml is fairly limited. So, keep this in mind when thinking if the pro-dev tools and ALM practices that are based on direct source code manupulation are going to be a fit for the low-code app developer team or not. Your Power Platform experts need to be primarily fluent with the admin tools from MS and the community (always start from XrmToolBox), plus they’ll need excellent skills for using collaborative tools like Teams within your org to share their lessons learned. Once you’ve got this side is covered, then you can move onto Azure DevOps and the likes.

    Environment management is another big topic for low-code apps on Power Platform. Having a separate CDS environment for every developer working on their corner of an application is Microsoft’s recommended approach to keep changes isolated. As your number of “ALM enabled” apps in the tenant will grow, the total number of environments will grow even faster. Assuming a theoretical 5 GB size for the CDS database of an environment, the $200/month storage cost itself wouldn’t actually be that significant if it saves a few hours of work from those developers. What you don’t want to happen, though, is having dormant dev environments consuming CDS capacity for many months with no actual deliverables from them – especially when your CDS quota is defined on a tenant level with no control available for reserving it to specific apps/environments.

    There are remedies to this problem. The “governance way” is managing the environment creation/deletion though a process that provides transparency to environment usage and enables allocating costs accordingly, for example via custom apps built on top of the CoE Starter Kit. The “ALM way” is provisioning on-demand environments from the source code in your repo via DevOps automation, then scrapping them after the active development work stops. While I sort of fancy this idea of “everything as code” where all of the infrastructure and configuration is managed via the same pipeline, I can’t help thinking that the most difficult thing about environments for business app development isn’t necessarily the configuration or the code. It’s the valid test data needed for making the app come alive. Yes, of course you could also script the perfect test data set to be generated alongside the environments, but again, we’re taking the level of effort needed in achieving deployment automation onto a very non-citizen developer level and approaching the XKCD scenario.

    Managed Solutions: what do you REALLY want to manage?

    Whenever Microsoft talks about ALM, usually you’re going to hear their statement on “use only managed solutions in production” sooner later than later. It’s not surprising that also the latest guidance, such as the MBAS 2o20 sesssion on Advanced Application Lifecycle Management capabilities lists this high up on the ALM Health Check list:

    In the user community around XRM there’s been an endless debate around whether unmanaged or managed solutions are really the way to go, and we’re not going to find the ultimate answer to it here in my blog. Personally, I’ve always had a hard time understanding the exact benefit that a customer organization would get from self-imposing the limitations of managed solutions onto themselves. It just sounds to me like installing a different lock with a dedicated key onto the window blinds in every room of your house. Expensive, overly complex, and very likely to leave you in the dark when someone forgets which key was used for which lock. It can also give you a false sense of security, as the main door to your house is still left completely unlocked, because Microsoft doesn’t yet offer a way to protect your production environments from the deployment of unmanaged customizations by anyone with sysadmin rights.

    In the context of low-code specifically, if you don’t have a seriously mature ALM process in place, I’d say you’re fairly likely to hurt yourself when playing with the sharp objects that are managed solutions. This is why during my 10 years of working with Dynamics CRM, XRM and now Power Apps, I haven’t yet deployed a single managed solution inside a customer specific project. On the other hand, I have worked with removing managed solutions created by the customers’ previous partners, after the ALM process has broken down for one reason or another (“not existing” being one of them), then replacing them with an unmanaged layer of customizations that has been a better fit for their overall CRM landscape. Yes, those other partners probably defaulted to following MS instructions on using managed solutions in every production environment – this guidance remained the same since CRM 2011 days, after all.

    Please do note that I’m not saying managed solutions wouldn’t serve a purpose. When you are building an actual app product that is meant to be deployed across multiple environments for different customers, managed solutions are of course the way to go. They offer the container for keeping your stuff separate from the stuff delivered by other app vendors, when deployed into the single CRM system that’s used widely across the enterprise by different user groups for different processes. Any proper commercial product development initiative should also be able to absorb the ALM overhead from environments, automation etc. and turn that into increased revenue from being able to ship software releases faster and more reliably as time goes by, thanks to the upfront investment made. It all makes sense here, but this is a very different landscape than how I perceive the typical use cases for low-code apps within organizations to evolve as Power Platform becomes more widely adopted.

    Remember: you’re no longer building “one place for all customer data”, rather you’re often creating several targeted apps for very specific purposes and audiences. Most of these app experiences will likely be fully developed by either savvy citizen developers, an in-house team of Power Apps champions, or an external consultant brought in to get that job done. The app lifecycle can be very short, even targeted to be used in one-off events (or under temporary disruptions such as COVID-19 social distancing), whereby some apps may actually be “disposable by design”. These are pretty much the opposite of monolithic CRM systems where a wealth of different ISV solutions need to peacefully co-exist throughout the years. So, whichever solution strategy you choose for your Power Platform environments, make sure it solves a real problem that your low-code app developers and admins are facing, rather than directly adapting practices that have been designed for the ALM needs of pro-developer teams working full-time on shipping a sizeable amount of custom code alongside the low-code application platform configuration information.

    A different approach to ALM: Power BI deployment pipelines

    The broad umbrella of Microsoft Power Platform covers also technology that isn’t (currently) built on the solution framework: Power BI. Since it is in practical terms more part of MS Data Platform, the mechanisms used on the BI side are understandably quite different than those originating from the citizen-dev PowerApps (back when it was still spelled together) or CRM systems. What makes this an interesting area to observe is that from what I’ve understood, the traditional development of reporting solutions hasn’t exactly followed the typical software development path either. Checking in reports to source control systems may not be the natural workflow of a Power BI content author or data analyst, so the barrier for adopting advanced ALM practices is likely to be pretty high for this audience, too.

    Power BI deployment pipelines is a feature that has recently been launched in preview. Labelled as an ALM solution, as also Power BI now packages report content into “apps”, this functionality is actually baked right in to the native user interface of the PBI service:

    deployment pipelines landing page

    Reading the introductory text gives us an idea of how this feature is positioned:

    Deployment pipelines help enterprise BI teams build an efficient and reusable process by maintaining development, test, and production environments. BI creators can incrementally transition new or updated content between environments, reconfiguring them with the appropriate data connections and permissions. Pipelines are very easy to use and take only few minutes to setup. No previous expertise or coding skills required.

    Wouldn’t it be nice if we could take the term “BI” from that paragraph, replace it with “App” and have a similar story to tell for low-code business app developers? A targeted experience that would be readily available for each & every customer environment right out of the box would certainly be the most effective way to democratize healthy ALM practices.

    You’ll need Power BI Premium capacity for using deployment pipelines, so the reporting ALM story is aimed towards the enterprise audience. If there ever was a native deployment pipeline functionality for Power Apps, I’m sure the usage would require consuming some type of paid for capacity from the Power Platform product subscriptions. I believe this would still be a lot easier approach for selling the idea of why customers need to invest in having proper ALM infrastructure and capabilities in place, since it wouldn’t be just an extra layer of billable hours added on top of app development project budgets but rather something much more tangible.

  • Licensing is NOT a security mechanism

    Licensing is NOT a security mechanism

    Licensing remains a topic that no one claims to like yet everyone keeps on talking about. October 2019 saw what was undoubtedly the biggest number of changes to Microsoft Business Applications SKUs (i.e. items that MS sells), with the end of Dynamics 365 Plan licenses and new models for licensing PowerApps & Flow. Not to mention the new structure that ties licenses closely to API call limits. Oh, and we’re still waiting for the new restricted entities definition that should have gone along with October 1st licensing terms.

    We’re not even past the month of October and there’s already a new licensing discussion heating up in the MS customer and partner community. The announcement of Self-service purchase capabilities for Power Platform products, made via Microsoft 365 Messaging Center (only visible to admins), seems to have pretty much angered everyone who saw it.

    I gotta say, you simply could not find a worse channel to announce something like this, because it’s aimed squarely at getting around a problem that IT administration (and sometimes consultants like me) are a part of. But like we’ve seen so many times before, communication isn’t exactly the strongest part of Microsoft’s software licensing management efforts, so let’s just move on and start analyzing what is happening here, why it is happening and what possible outcomes there might be from it.

    Empowering every individual to acquire applications

    To get an overview of what exactly is going on, you can read the article from Mary Jo Foley: “Microsoft to enable end users to buy Power Platform licenses without administrative approval”. In short, starting in November 2019 (in the US), any user that has an account in your organization’s Azure AD tenant will be able to go and buy Power BI licenses directly from MS. Later this will expand to PowerApps & Flow, and other regions. Essentially this will be an “insert your credit card here to unlock Power Platform functionality” type of experience.

    How is this different from any of the popular SaaS products from other vendors then? It isn’t. That’s the model that every consumer app and most business apps support, since it represents the lowest barrier to entering a commercial relationship. Usually you would start with a free trial period to try out the capabilities of the SaaS product. If it’s a good fit for the problem you’re trying to solve, the next problem you face is the procurement of the app. Buying things for personal use is easy, whereas the bigger the organization you’re working in is, the longer you can expect this purchasing stage to be. During it you’re basically standing behind the store window, staring at the product you know you’d really need, yet the door to the store is being kept shut. Often there’s even no opening hours sign to give you any clue on how long this will take (or if you’ll ever get what you wanted).

    In such a scenario, it’s not uncommon for problems to get solved with a credit card and an expense claim. The ease of taking this route is how Shadow IT came to be, and I bet we’re just going to see more & more of this Bring Your Own App (BYOA) activity in organizations as the information workers become more savvy about what’s actually out there in the cloud. If one store is closed, there are tens of other options with 24H service.

    But they can’t do this! They’re MICROSOFT!!!

    It’s one thing being an enterprise software startup and trying to get onto the radar of potential customers via the Bring Your Own App strategy. When you’re Microsoft, though, the expectation is that things work in a completely different way. Since pretty much every bigger company is a MSFT customer, the licensing game has been a process of long negotiations and complex agreements. This is the procurement norm of how Microsoft software finds its way into the hands of the end users. Well, it sometimes does, and other times it doesn’t, because the needs of individual users may get lost in the big corporate IT machine that’s trying their best to keep things under control, with the growing amount of regulations, systems and requirements.

    What’s Microsoft on about here with self-service purchases, specifically with this chosen set of products? Imagine you’re the world’s most valuable company, you happen to be producing software & you’ve recently discovered a huge new market in the Low-code Application Platform space. You’ve built up a strong community of advocates (or addicts even) and your target is to empower the next 10 million application developers to digitally transform their organizations with the help of your global cloud infrastructure and AI driven insights. You’ve got all these key buzzwords lined up, there’s a seemingly endless sea of citizen developer opportunity ahead of you. The only thing standing in the way of your success is this nasty thing that looks like Niagara Falls, sucking in many of the smaller boats that the poor citizens attempt to use to sail to this promised land of Power Platform. That thing has a name and it’s called Enterprise Software Licensing Models. So much for the “no cliffs” experience then – hope you packed a life vest on this journey!

    To avoid this vortex that Microsoft themselves have largely caused over the past decades with the swirls of their enterprise software sales strategies, it makes perfect business sense to open up new, alternative routes for those power users who seek to merely use the software tools – instead of catering only to those who are tasked with managing the whole lifecycle of IT tools in the organization.

    There’s only so much you can do with the PowerApps and Flow features bundled into Office 365 subscriptions, after which you’ll need a premium plan. Why on earth would Microsoft willingly push the users to look for alternative tools like Zapier or IFTTT to automate processes that connect to data sources that are outside Office 365? Why shouldn’t it be possible to enter the very same credit card details into a form provided by MS, to keep the tools within the same MS cloud that’s already used by the organization? Isn’t this actually a way to reduce the problems resulting from Shadow IT? Keep the rogue users closer to the official IT world and you’ll have a better chance of converting the tools into non-shadow status at some point.

    Rogue citizens

    Obviously there are some valid concerns with a model that might encourage users to acquire MS software via an alternative channel than the officially sanctioned one. The self-service shop won’t give the same negotiated prices for licenses as the company wide agreements. Handling the expenses from various different sources will be an overhead. The boundaries between supported and unsupported IT will become blurry. Even with the promised central visibility into who’s bought what licenses in the tenant, initially it will all just look like more work to those persons who have traditionally managed Microsoft licenses in the organization. There’s an FAQ document from MS for this self-service purchase model that attempts to address some of these concerns, but with a change like this there’s bound to be far more Q’s than A’s at this point.

    There shouldn’t be a need for the self-service purchase channel to exist, but in reality there is. If you have only spent time working in roles that represent the centrally planned deployment of IT systems, you may not realize the challenges that can stand in the way of you and the software license you would need for getting your job done in a larger organization. Sure, there might be a theoretical process in place for how the needs of business users are identified and then eventually turned into a working piece of software that everyone happily uses. In reality a fair share of the people on the business side who live in the world of needs may not be seeing such processes in action. They may well be unaware of any development initiatives on the IT side, nor have contacts with those professionals that could help them navigate these processes. If IT systems can be complex, then the inner workings of an enterprise organization can represent a whole new dimension of complexity. No one is at fault, yet everyone pays the price.

    (more…)
  • 4 directions for Power Platform business growth

    4 directions for Power Platform business growth

    It’s now roughly one year since Microsoft launched the concept of Power Platform. It’s been extremely interesting in the past 12 months to watch how this new platform strategy starts to play out in the world outside Redmond, as the pieces of this grand puzzle begin to become visible here and there. Having worked in the MS ecosystem on customer & partner side for 14 years now and coming from the Dynamics CRM side originally, this is the biggest single shift I have witnessed in their product strategy to date.

    Putting all the puzzle pieces together is surely not easy for anyone who isn’t devoting a sizable share of their time on consuming information from the various events, announcements, blog posts and documentation released by Microsoft. The thing that really makes it tricky is that this Power Platform thing isn’t confined inside a single bucket. It’s not Dynamics 365, it’s not Office 365, it’s not Azure. It’s all of them and yet none of them. Every MS partner and every customer decision maker will increasingly run into the product messaging, but they’ll hear it presented in a different way – and most likely interpret it uniquely based on what their background is.

    The only reason Microsoft would be investing so heavily in building and promoting the Power Platform is that they see a massive new business opportunity in it. As Steven Guggenheimer wrote in his recent blog post:

    “The Business Applications Total Addressable Market (TAM) is predicted to be at $125B by 2022, and 57 percent of this will be driven by ISVs. Dynamics 365 and the Power Platform are an important area of investment for the company, and represent a significant growth opportunity for partners in this market.”

    Accelerating opportunities for ISVs with new programs and technology – Steven Guggenheimer

    Big numbers, but that’s what they always are in these grandiose statements about global market potential. What I need to understand when talking with customers, partners and internal stakeholders at our company about the strategic direction of Power Platform is from where specifically might this growth come from? To help these discussions I ended up drawing the following diagram about the four different dimensions where I see this Microsoft application platform strategy creating new business:

    The way I see it, the growth will happen both A) inside Microsoft’s product offering and B) the outside world of customers and partners, within 1) the traditional business process management scenarios as well as 2) those processes that you wouldn’t have tried solving with any CRM style application/platform in the past. Let’s dive into each of these areas and I’ll explain what the impact of Power Platform might be in generating new business to run on top of this new Microsoft aPaaS (Application Platform as a Service) foundation.

    1. Dynamics products

    Let’s start from the most familiar ground. The place where the most concrete changes resulting from the Power Platform strategy have been felt during the past year must be Dynamics 365, and the Customer Engagement apps specifically. The platform formerly known as XRM is in the process of being replaced by what is sometimes referred to as “PowerApps platform”, although that may not be any official term that would stick. Regardless of the marketing lingo, the customizers and developers of Dynamics 365 CE solutions are right now facing a lot of pressure to adopt brand new concepts and tools that will replace those ~10 year old building blocks that XRM solutions were made out of. Compared to the earlier transition from on-premises to Online products, that may well have been a much easier shift to adjust to than this new Power Platform whirlwind that’s moving everything around on its path, from licensing to UI to SDK.

    From the perspective of the internal Microsoft world, the Dynamics product teams have previously been somewhat captive of the CRM legacy that came along with the XRM platform. As a commercial software product, it wasn’t originally built to be a pure platform, rather the design choices and customer requirements drove it more towards being an extendable CRM application first and platform second. In the process of migrating Dynamics 365 CE Online to run on Azure services, the platform and the applications were separated from one another. To balance things off, there’s also been a huge unification process initiated with the client side technologies, where the target is to remove the barriers between Model-driven and Canvas apps, to Run One UI. The platform tools like PowerApps Component Framework (PCF) now give also the internal product teams a far more agile path forward in deciding what kind of features and experiences the specific apps like Sales or Customer Service should contain. What this means is that the stagnation period where everyone had to just wait for the new platform capabilities to become available may be coming to an end and in the next release waves we can expect a significant growth in new app functionality being shipped to Dynamics 365 customers. In other words, a growth in application depth.

    Alongside this internal platform development, another huge benefit that Dynamics 365 as a business has gotten from the new direction at Microsoft is the closer connection with the Azure teams. A few years ago there was still the MBS silo to keep up the walls between CRM & ERP business and the mainstream MS product business, which explained a lot why we didn’t see so much of the Azure innovation trickling down to the business applications built by the same corporation. Now the tables have truly turned as we’ve witnessed all of the new applications like Dynamics 365 for Marketing betting heavily on the very latest Azure services. AI is getting infused into every product at Microsoft, but it also gives birth to brand new products like Sales Insights or Virtual Agent for Customer Service. To link all this with the Power Platform story, it’s important to understand that this platform side is what eventually allows customers and partners to customize these new apps and services to meet their real life business requirements. The growth potential in this Dynamics products segment is being amplified by the fact that PowerApps, Flow, Power BI and CDS give it the extension points needed for going beyond packaged SaaS apps. The growth in Dynamics 365 app portfolio width is therefore driven by the Power Platform connectivity with Azure.

    2. Other Microsoft products

    While the merger of Dynamics 365 CE and PowerApps platforms is a great boost for the Dynamics products, that’s not the only area within Microsoft that is touched by the Power Platform strategy. Office 365 has of course been the biggest product display window for PowerApps and Flow, due to how services like SharePoint and OneDrive have been deeply integrated with these tools. There is a Microsoft 365 Business Applications partner program that interestingly enough doesn’t seem to align with the “actual” Microsoft Business Applications group’s activities at this moment, as it sits within a different organizational box, the Modern Workplace solution area. When you think about the origins of how the previous generation apps for information workers were often built on top of the ubiquitous SharePoint Server, this arrangement does make sense, but I wouldn’t expect these separate boxes to remain forever in place. After all, what’s been happening to PowerApps recently in terms of commercial success is “like SharePoint all over again” (according to Charles Lamanna), so all roads here lead to the Power Platform being the growth engine for Office 365 and Microsoft 365 to reach further into the customers’ information management needs.

    (more…)
  • Building The Platform for Every Developer

    Building The Platform for Every Developer

    For the first time ever at Microsoft Build conference, the Power Platform was presented right at the start of Satya’s keynote this year! Woo-hoo!

    Of course this time last year there wasn’t yet the name “Power Platform” to even reference at Build. We had only just seen the merger of XRM and PowerApps into something that was a bit of a puzzle to communicate to partners, let alone customers. Well, the puzzle hasn’t exactly been solved yet, but it is still quite remarkable how far we’ve come in one year already.

    Last year’s sessions at Build 2018 were mostly about introducing the concepts like Common Data Service to a .NET developer audience that probably had zero hands-on experience with any Dynamics product for the most part. Not a whole lot of noise was made about this entry into the #MSBuild space. Fast forward to 2019 and now the vision of uniting pro developers with “every developer” is already touted at the keynote sessions. Not just that, but Satya is saying that recent re-architecting of Dynamics 365 on top of Azure infrastructure and services should be examined as an excellent reference for anyone who’s planning to build their own products on SQL Azure.

    During the week of Build, the product team behind Citizen Application Platform (“CAP”) puts aside their Citizen caps and pulls on the pro dev hoodies to talk about topics like solution management, PCF component development, Azure Functions, DevOps pipelines and all the nerdy stuff that would scare away the folks who normally create PowerApps. It’s inevitable that as the tools for app makers get more mature the next barrier to world domination will be in getting not just the IT admins to build the necessary automation and governance around Power Platform in enterprise environments but also in finding a way to make pro-coders play with low-coders.

    If you look back at XRM, then there’s really nothing new about this division of roles. It has always been the case that code illiterate business analysts do the point & click configuration work for data models and business processes, while the XRM developers spend their time with the SDK enabled client-side extensions, server-side logic and system integration tasks. Fundamentally what the Power Platform does is it enables everyone to level up in their game. Application design on the UI level and interfaces to connected data sources can now be handled by those business analysts who are willing to learn new low-code tricks. Similarly, the developers get to break free from the boundaries of the IIS and SQL Server boxes, to harness the amazing power of The World’s Computer (Microsoft’s nickname for Azure) to hook into new AI services and crunch the contents of The Real Common Data Service.

    If the app builders are about to step up their game, so must the sales machine of Microsoft. The big push from Redmond is now on ensuring that an ecosystem will emerge on top of Power Platform. The new partner program for Business Application ISVs, lead by Steve Guggenheimer, is trying to make a bigger splash by combining the earlier models of Azure Marketplace and the Dynamics 365 focused AppSource into a single channel that could actually serve the grand vision of a no-cliffs development platform. As always, you should check out what The Other Steve has to say about the upsides to the new program, before making your conclusions on whether it’s just a new tax on ISVs or an opportunity worth pursuing for a growing number of MS partners.

    To summarize the announcements and buzz around Power Platform at Microsoft Build 2019 conference, I’ve compiled this handy lil’ Twitter Moment for you to enjoy:

  • In Praise Of Code and No-Code

    In Praise Of Code and No-Code

    Two weeks ago Neil Benson wrote an excellent article on LinkedIn, as a response to a claim that everyone working as a functional consultant in a Dynamics 365 project team should also know how to write code. This really resonated with me and I shared the article, along with a bit of commentary of my own. My post, in turn, started to gain quite a lot of traction on the LinkedIn feed. It looks like we had touched upon a topic of great interest within the network of CRM professionals.

    If you read my post above, it pretty much summarizes the main points I wish to bring out in this discussion:

    1. There is much more to ensuring Dynamics 365 project success than being able to do hands-on software development.
    2. A big chunk of the value delivered by Microsoft’s cloud platform is not relying on custom code development.
    3. The remaining chunk that is custom code driven work should be left to professional developers and not copy-paste heroes.

    There have been some very good arguments written in the comments section of the LinkedIn post, so I urge you to also view them for gaining greater perspective on the topic. I see a lot of resemblance with the “should designers code” meme in the original assumption that functional consultants would be able to do their jobs better if they also were familiar with developing custom code. Much of what has been said in the heat of that debate between coders and non-coders probably applies here, too:

    Alan Cooper’s four part article covers the dilemmas in general software development teams with such great insights and depth that I won’t even attempt to dive in the same direction here. In practical terms of a CRM project, when it comes to the availability of skills and experience needed in carrying out the wide range of tasks during the project’s lifecycle, the manager in charge of resources is always going to need to do some juggling. The less you ask the team members to juggle between completely different kinds tasks, the more likely they’ll able to focus on actual customer value generating activities rather than keeping all the balls in the air simultaneously. Here’s how Neil Benson put it:

    “Asking a functional consultant, with no formal computer science education or experience as a professional coder, to find and copy someone else’s JScript from Stackoverflow and paste it into your Dynamics solution is asking for trouble.”

    I don’t touch code myself but I do try to get my hands dirty on a wide variety of technologies. For example, today I spent a few hours getting familiar with Azure Service Bus, testing how without writing a single line of code I was able to push plugin execution context data into a cloud based message queue and work with it via a GUI in Azure Logic Apps. Now, I would never recommend myself as a person you should hire to set up your production ESB, but I do feel like I need to have a deeper understanding of these technologies than I could gain just by watching through the flashy demos in Microsoft keynotes. Seeing the different sides and reading/hearing what those with deep expertise on a particular technology have to say about it, that is essential. Going and actually trying to step into the shoes of an expert for that technology – probably an unnecessary detour.

    Skimming the bits from the top without diving deep into the dirty details of writing real code might sound like being afraid of all the complexity that awaits beneath the surface. However, the lack of code in a solution doesn’t mean that the complexity of the solution couldn’t be high. The CRM Tip Of The Day post “The story of the small change” perfectly illustrates the way in which individual configuration items built entirely via the graphical tools provided by MS can have dependencies that require you to have a rigorous testing process in place. It’s not just the changes of a system either, since you can easily use workflows and business rules to build a level of complexity into your business logic that doesn’t reveal itself in the test scenarios the consultant behind the design might have thought of. Whether you’re delivering the end product via code or configuration, bugs will sneak in there and eat away a part of your life – be it before or after production deployment.

    The argument for doing things via point’n’click configuration “because it’s so much faster to build” shouldn’t be the one and only argument. Yes, it is often much, much faster to put together the first iteration of a solution via graphical tools. This in itself can be a huge value for the business because you can validate the proposed solution quickly with the relevant stakeholders. Often you’ll only get to the actual requirements when demonstrating live parts of what the initial requirements said. Now, the main reason why Real Developers are often afraid of what “citizen developers” might come up with when given quick tools for building no-code apps is that they may lack the experience of seeing the full lifecycle of a business application. They’ll mistake the first PoC as being equivalent to the final production solution, with little thought given to the work that still remains ahead. This experience isn’t something you must necessarily gain via writing code yourself – a no-code functional consultant just needs to gain sufficient exposure to the various stages of the process via working as a part of the CRM project delivery team.

    I think we all need to be able to see “beyond code” when building solutions on top of platforms like Dynamics 365 Customer Engagement. Going full-on no-code in your design approach is probably going to unnecessarily limit the value that could be gained from an extensible application platform, forcing you to unsustainable workarounds and resulting in poor UX for the system end users. At the other end of the spectrum, always resorting to your custom built components before having a thorough analysis of the configuration capabilities and complementary cloud services found within your ecosystem of choice will likely increase the solution’s TCO and put the long term reliability of your complex business application at risk as changes in related processes, personnel and technologies occur over time.

    Please feel free to leave comments on how you see the role of code & no-code work evolving in Dynamics 365 projects.