GenAI MicroApps are changing how IT uses the Cloud

In my previous posts, I commented on the SuperPowers that GenAI has granted to employees regardless of the business function they perform to help companies operate, innovate and profit.     

As a cloud and AI architect, in this post I will instead reflect on how GenAI is impacting the emerging trend of enterprise micro applications . Perhaps this is a new concept for many of you. Let's first start by shortening the name to MicroApps. Less typing, less reading is always better.  While I will define the term in a more comprehensive way later in the article, for now let’s just think of MicroApps as nimble, purpose built, limited scope software applications that provide great value to enterprises. This class of applications are ideated within business departments, rather than in the offices of Enterprise IT.  This time IT plays an observer role. Time to value is measured in weeks. A new recipe? Perhaps.

My main hypothesis for this article is straightforward.  For the first time, the technology landscape has converged into a coherent set of capabilities that will facilitate the rapid delivery of much needed business functionality, through a new generation of secure, well integrated, MicroApps that will leverage the best of existing cloud native services, architecture, and operational best practices. MicroApps will also fulfill the broader promise of Cloud as a utility model through a re-definition of what it means to “develop” applications.

Hatching MicroApps

So let’s imagine this new superpower in a less abstract way.  Let’s  imagine an Executive Director leading a marketing team who works for a fictitious enterprise operating in the healthcare payer space.. He has grown frustrated with the company’s web content management and CX/DX platform, which has grown into a monolithic, overly complex, not very user friendly system. 

Articulated in mini-PRD style, this executive director has hatched a conceptual vision for a specific unit of business functionality that addresses his problem. Because speed is of the essence, rather than embarking on the traditional journey of engaging with IT, the executive director sees an opportunity to tap into his new AI-based superpower. This example is a perfect use case for a MicroApp.  Finally, flexibility, freedom, and an efficient path to delivering rapid fire innovation powered by AI.

Here is what the marketing director might propose to the agentic co-worker through some thoughtful prompt-engineering.

Marketing Executive Director: Build us a MicroApp that allows authorized marketing teams to build microsites to support periodic sales and marketing campaigns. The core requirement of new  microsites is to help introduce new upcoming programs, targeted at Gen Z members.  Each of the microsites must be securely implemented in the company’s approved, compliant, secured hyperscaler of choice. The sites will recognize two main personas. The first persona is represented by target members who will have access to the public component and page of the microsite  The second persona will be represented by the maintainers, and operators of the site. Operators will be subject to administrative security and content publishing must require integration with the company’s SSO facilities. The site must allow the safe HIPAA compliant data transfer from the website, to internal staging areas, with auditable access by select, authorized employees.  Each site must need to be protected by CAPTCHA configuration to defend against bot attacks.Maintaining alignment with corporate branding is paramount. However, the sites must not stifle creativity and innovative design.  By accounting for existing design systems and guidelines, the sites  must also promote and facilitate the application of a new design system, derived from the corporate base system, thus ensuring a strong level of brand continuity and alignment with the corporate mission and intent.  The new marketing tool must also ensure that any resulting microsite is automatically integrated with the company’s existing Google analytics platform.  For ultimate content management simplicity and efficiency,  the data for building and maintaining each microsite will be provided in a shared OneDrive folder that contains MS word files for copy, and images and videos in standard formats.  Microsites , by default, will be active for only 30 days. This duration can be controlled through configuration. Lastly, operators must have facilities to manually deactivate each microsite, and ensure that upon phased deactivation. All data resources shall be archivable for future analysis . 

Why is this conversation between a business leader and an AI so intriguing? Many reasons. First of all it is entirely conducted in the English language. Second, it is filled with implied environment and system knowledge. Third, and most importantly is the fact that this human to computer exchange empowers an entirely new, untapped class of citizen developers, to become the true innovation engines for Enterprises in the era of AI.  When citizen developers have such power at their finger tips, and become the makers of innovation, then it is easy to state that the “democratization of  innovation” is upon us, as Sam Altman of OpenAI has called it.

This hypothesis will serve as the inspiration for a series of articles that will hopefully encourage lively debate and provide value to the broader LinkedIn audience.

Now back to definitions, but feel free to skip the next section.

Legacy MicroApps : Definition and Challenges

First of all let’s define what we mean by “Micro Enterprise Applications”. MicroApps are software realizations  of business functionality. In other words, they are simply units of software, often bespoke. They have existed for a long time, yet they have not been examined through a more independent lens. In the past they were referred to as “application modules”. We have known them as “applets”,  or “ancillary applications”. But often they were simply filed under the rubric of plain old examples of system customization, injected and layered into commercial software products. 

Historically legacy MicroApps have represented the components that were bolted on, perhaps force fitted into monolithic systems.  We find them in ERPs, CRMs, and various HRIS platforms. They are present in the worlds of IT and OT systems.  Often, the system integration glue needed for them to operate was greater than the application component itself. As technical analysts, many of us have even recognized the presence of MicroApps in places where they truly did not belong. For example when the ETL platform morphs into an organization’s core repository and custodian of business logic, real problems emerge. These subsystems de facto become small applications in their own right, implemented in the wrong place, using the wrong architecture.  Many of these applications pushed the limits of the technology they were built on, often exceeding the original design specifications and intended use of the runtime platforms. They also broke or stretched the process of software development and skipped any form of best practice.

Let me pause the negative narrative for a second. It is true that legacy MicroApps have certainly provided enterprises with benefits and utility. Sometimes being responsive to the business is imperative.  But, like everything else in IT and engineering, unintended consequences emerge when trade offs are made. At a general level,  it is often observed that the design and engineering of legacy MicroApps has been approached in the wrong way.  Often developers expanded business functionality through a “copy and paste” strategy, ignoring the real precepts of reusability. This approach, while useful in moderation, was abused. We have all done things like this: take a body of code, clone it, make a few changes, and then add it to the system. Sound familiar as a workflow? Mea culpa, mea culpa!  In other scenarios,  functionality was hastily implemented in ways that sacrificed the valuable architectural pattern of decoupling modules. Programmatic elegance? Not important. The result: a monolithic system became even more rigid, monolithic, a massive boulder of code with unproductive levels of tight coupling of code , and data.  These are some reasons why today, legacy MicroApps have become a liability. 

What kind of functionality did legacy MicroApps implement? They implemented new mechanisms for data collection. Perhaps these should have been nimble, standalone code units that could have been delivered to an enterprise portal.  MicroApps have often implemented collections of complex reporting logic that was layered or forced into a custom codebase, or thrown into commercial products.  Perhaps a layered architecture built on data virtualization and on powerful data visualization such as Tableau would have done the trick. Ever think about how field service apps or your hospital’s EMR mobile app have been built?  Most of them emerged when mobile became technologically viable, long after the original core business systems were built. And most of them were engineering bolt ons, all suffering from stability, usability, and even security concerns.  If you dig a bit you find that your mobile healthcare apps may have a ton of dependencies on MUMPS, the programming language, not the malady. Side note: MUMPS was born 1966. I say no more.

Because of these excesses, today many of us are spending significant effort fighting and addressing  technical debt.  System maintenance and integration is more difficult than it should be. Upgrades are complex undertakings. Legacy MicroApps  introduce friction that makes upgrades difficult, often perpetuating vendor lock-in for off the shelf solutions.  Custom software is not immune. Legacy MicroApp friction forces enterprises to continue using, often for decades, systems that should have been retired. It is no wonder that legacy environments such as mainframes still run a lot more COBOL than they should be.  Likewise, as encountered in my own modernization practice experience,  there are some custom ERP systems written in RPG, that now have been a critical liability due to a lack of skilled workers.

Let’s move on. AI to the rescue.

Near-Term MicroApps: How Building with Cloud is Changing

GenAI is changing the way we work, regardless of our roles in business. Ubiquitous, multi-modal Generative AI is rapidly being deployed, integrated or built in almost anything that includes any form of a digital component (read HW and SW-based). Consider the following. Smartphones? Of course. End user computing devices, including wearables. No-brainer. Refrigerator ? Why not? Jony Ive’s new thingamajig, whatever that might be ? You bet!

But it is not only how we work that is changing. It is also how we use the cloud that is itself changing. Let’s reflect on this. Let’s look back at the earlier example of our executive director, innovator and citizen developer, who works with his agentic co-worker to build and deploy a solution for delivering marketing microsites. 

With minimal, if any involvement from traditional IT teams, today a business executive, with a small dose of training, is able to address real problems. At the same time, the embodied intelligence and technical expertise of the agentic system is also able to address the deficiencies, the gaps and challenges that plagued legacy MicroApps. It’s a win-win situation.

In many cases, these  MicroApps will become part of a larger solution to address technical debt, by applying a divide and conquer strategy, with the key difference that the driving force will not be IT but the business SMEs themselves. 

The AI that builds them, prompted and guided by the human , will produce high quality artifacts. The technical architecture will be based on proven software patterns, created by the most talented of humans, and eventually captured, and shared by the foundational models themselves to benefit all.   Best practices for cybersecurity, for compliance, for observability will all be  reflected in the code and the configurations that the AI creates.  

When it comes to the cloud, the infrastructure matters less and less. The Cloud is seen by the AI as a black box, a utility layer that is plugged into, just like the electricity that powers our toasters in the morning.  The AI knows and sees the mature collection of services that the cloud service provider brings to the table.  

One more thing. The AI is not alone. It is aware of other tools that can make the construction of a MicroApp simpler, more reliable, and architecturally cleaner. Specifically, the AI that the executive director co-creates with, is actually a team of agentic capabilities that work together. It's an intelligent, technical and business savvy army that plans and executes tasks autonomously. The Executive director becomes a conductor, a composer, a “general contractor” of sorts, but his hands won’t ever become dirty, callous as he will work with his mind, human sensitivity to articulate new solutions, and expand on small sparks of originality. 

So, it should be no surprise that then something like a next generation of MicroApps will also be one of the fruits of the innovation that Generative AI will hatch for humanity, or at least for  the world of IT.  And it won’t be a surprise that the locus of innovation will reside in executive directors, in the average business leader, and primarily not hot-shot programmers. 

Agentic MicroApps Builders: Enabling Prerequisites

I know. This all sounds a bit futuristic, ahead of its time. But the magic can be real if we fulfill a few assumptions and prerequisites across a few domains.  Many enterprises are on their way in meeting these requirements.

An Established Business Glossary:  This is an important custodian of the company’s business lingo, and branding. It is natural language rich, perfectly consumable by AI. 

An Implemented Cybersecurity framework:  It includes zero trust architecture covering IAM for employees, AI coworkers, and 3rd party contractors

Established, Proven Design System: A clear, referenceable  set of specifications web,mobile and multi-media artifacts that capture the essence of a company’s brand or brand capture 

Established Data Ontology:  A standardized way of navigating the corporate data universe, existing and future, built for internal, and industry facing consumption and sharing. AI consumability implied.

AI-Adapted DevSecOps: Automation first approach to building and maintaining software, processes that teams of co-developing teams of traditional developers and AIs . Includes next gen Internal Developer Platforms.

Continuous AI Model Evaluation:  Automated, integrated development of models, performance measurement using emerging multi-modal, multi-LLM judges to ensure quality, compliance, alignment

Here is some good news. If a company has gaps relating to this list, AI itself can help define or discovery, validate, document, repackage for easy agentic integration. For example, automatically generate specialized MCP servers that the AI can consume as tools.

So now is the time to capture the deeper characteristics about modern MicroApps.

Modern MicroApps: The Characteristics

What are the characteristics of modern MicroApps. One when to catalog them is to fall back on time-tested organizing framework, a conceptual trio that includes aspects around: 

• People 
• Process 
• Technology

These facets help us define the characteristics of GenAI powered MicroApps. This section will capture a few thoughts, and plant them as seeds for future articles. Readers are encouraged to select from the list items for future examination.

People  - The Who and The Why

1. Empower  a new class of “citizen developers”. 
2. Target business user community (department level) 
3. Are purpose built (single task or focused workflow)
4. Offer Focused Scope .
5. Plan for a limited shelf life by design.
6. Develop a predictable, time-bound financial Investment 
7. Leverage multi-modal interaction by design, including “prompt in place” 

Process - The Business How  

1. Start with a strong Design Thinking infusion (customer empathy) 
2. Follow specification based collaborative engineering between humans and Agentic systems
3. Apply accelerated development lifecycles ( The Three P’s: Prototype, Pilot, Production) 
4. Realize agility through fail fast, fail early strategy
5. Prioritize Speed and fast time to Market 

Technology - The Engineering How, and Why

1. Prototype and communicate vision through  Low Code/No Code 2.0
2. Lightweight monoliths architecture (rebalancing micro-services)
3. Leverage Cloud-based, private or public,  deployment and delivery
4. Apply best practice-based cybersecurity operations
5. Incorporate best practice-based business activity and KPI Monitoring (BAM) 
6. Engineer using cloud native services, mostly PaaS (serverless computing)
7. Ensure observability and technology monitoring best practices
8. Elevate Data Integration to first class citizen
9. Deliver feature and functionality through agentic collaboration and composability, not APIs This checklist is comprehensive, but by no teams complete. The reader is encouraged to suggest additional 

This checklist is comprehensive, but by no teams complete. The reader is encouraged to suggest additional themes.  Before I wrap up , a few more words on evaluating trade offs, a conservative pause to consider challenges and concerns

Challenges and concerns

There is certainly a lot here to consider and review across these defining characteristics and assumptions. Some are easily answerable as best practices have been tested and proven. In other cases, such as continuous model evaluation,  the art and science is evolving and progressing day by day. The evolution of these topics opens up an opportunity  over the next few months, to experiment, learn and report.  Stay tuned. For now, let’s go back to the title, and address the theme of cloud architecture impact.

Concluding Thoughts

And now time for a recap, and final thoughts. We have seen how an executive director in the marketing department is now able to exercise a newly discovered superpower. Using natural language with an agentic co-worker, his business executive can now build software. Yes, build, just like teams of engineers do.   Did it sound easy? No doubt. Why is this different compared to the status quo ?  

The most evident difference is that a non-technical business user is articulating what the department needs, and is doing so in natural language. The AI knows the company, its practices, its brand knowledge. The AI also has deep implied technical awareness and knowledge of the target environment components (cloud provider, SSO provider, Object store etc) as implemented over time within the company.   It has access to “tools”  (APIs, advanced MCP servers, traditional APIs, etc). It knows the best practices crafted over years but the IT department, a rich assembly of concepts, approaches that embody the wisdom of the crowd. The AI is also technologically frugal. While each of the hyperscalers sport hundreds of complex cloud native services, in reality smaller systems only require a small subset of them. In the pre-AI world, there was cloud waste. Often too many services were used , leverage to implement functionality. Sometimes various generations of the same cloud native service were being used, contributing to subtle technical debt. An agentic co-worker that builds MicroApps, acting as a cloud architect and engineer, would be adept at native service selection, would avoid waste, and would reduce costs. The agentic AI co-worker would design and implement, through established patterns,  optimize the surface area where problems can occur, cybersecurity included, so that less can go wrong. 

These last details are the most important impactful considerations when it comes to architecting in the cloud. In the pre-AI era, delivering on functionality like a reusable marketing micro-site generator, would have required an adept cloud engineer assisted by a DevOps SME. With AI, the role of these experts would be very different. While these traditional resources may selectively participate in the validation and quality control steps of the lifecycle, the heavy lifting will be performed by the agentic layer that defines, configures, builds, tests, deploys using automation,  according to platform best practices and company standards. What does this mean ?  Simple.  Expanded productivity for all .  Shorter time to innovation Shorter times to revenue.  This is how GenAI MicroApps are changing how IT uses the Cloud. This is how non-technical users , when granted AI SuperPowers, become the true innovators. 

You might have noticed that I subtly inserted the words “near-term” in my description of MicroApps.  This  was done just to ensure the reader is cognizant of the fact that the field of AI is progressing and expanding so quickly that it is impossible to project what lies ahead across a time horizon beyond five years.  The quantum and rate of innovation in the space of AI is not uniform in the amount of progress and breakthroughs they bring about. Therefore it would be pure speculation to say that once AGI has arrived, the most intractable problems that mankind has tried to tackle will become solvable. It would be speculative to say that AI will be so powerful that it will recursively challenge itself, to consume all existing human knowledge,  whether explicitly analyzed or passively recorded,and use its capabilities, and capacities to “go where no man has gone before” . Perhaps I liked the movie “Lucy” a bit too much , or perhaps I am just a good old fashioned trekkie.

Related Articles

Design Systems meet GenAI: the intersection of multi-modal UX, guardrails and compliance

https://www.linkedin.com/pulse/design-systems-meet-genai-intersection-multi-modal-ux-bisignani-6prde/