Lasting Impact of the Little Language that Could: Smalltalk turns 50

Late 60’s and early 70’s Xero was a major player in the office automation space. Innovative work on user interfaces was happening at Rand Corporation(JOSS, Tablets, GRAIL), Stanford Research Institute (Doug Englebart, Personal Interactive Computing, Mouse etc) and MIT/Lincoln Laboratories (Ivan Sutherland / Sketchpad). Xerox gave Alan Kay and his team at their Palo Alto Research Centre (PARC) free reign to explore human computer interaction. Alan had worked on ARPANET and did a PhD on the FLEX machine, a precursor to a truly personal computer. He conceived the “Dynabook” which conceptually defined a tablet (think iPad, but easier for the user to program and tailor) in 1968!

Amazing things came out of PARC, including:

  • Object oriented programming for UI and general purposes

  • Smalltalk (still one of the best, purest, easiest to learn and productive general purpose languages available today)

  • Keyword syntax facilitating domain / application specific languages

  • Just in Time Compilation (JIT) and Virtual machine execution of bytecodes allowing systems to be ported easily across hardware

  • Integrated Development Environment (IDE ) with introspection

  • Bitmapped displays with graphics and fonts

  • Image storing state of system allowing easy and instant persist/restore and continuation of work

  • Model View Controller (MVC) paradigm for separation of domain model, business logic and user interface

  • Windows, Icons, Mouse and Pointer (WIMP) paradigm with overlapping, resizeable windows and the whole Graphical User Interface

  • Text, Image and Document editing with What you See is What you Get (WYSIWYG)

  • Laser printing

  • Ethernet

We owe these pioneers a major debt of gratitude! Subsequent developments include:

  • GUIs at Apple (licensed from Xerox) then Ms Windows (Imitated)

  • Objective C, the major systems language at Apple (Smalltalk ideas and class libraries on top of C) - the precursor of Swift

  • Object oriented databases

  • Office suites - Charles Simonyi did Bravo at PARC on the Alto system, the first WYSIWYG document editing system. He later spent 20+ yrs at Microsoft and created Word and Excel

  • OO in general, Smalltalk being a major influence on Java, Javascript, Ruby, Eiffel, Dart and many other languages. It is a direct ancestor of Squeak, Pharo, Amber and Newspeak

  • eXtreme & Pair programming (Kent Beck, Ward Cunningham) and aspects of Agile Development

  • Live programming/ debugging

  • Test Driven Development (SUnit, Kent Beck)

  • Agile Visualisation (Roassal)

  • Moldable Tools (Tudor Girba, GTools)

  • EToys and Scratch visual programming for children

I saw Smalltalk ideas in the 1981 Byte article, got hands on and seduced in 1991, and we have used it ever since in our products and tools. Capers-Jones 2017 research confirms Smalltalk still offers a 2-3x productivity improvement over mainstream languages. Vive la difference!

Application Portfolio - Deriving Value from the Asset

The application portfolio in mature organisations represents a very significant investment over an extended period. Expenditure can easily run into hundreds of millions or even billions. This can be a major asset to leverage to produce value, or a major problem that consumes resources and funds.

Managers, architects and analysts often don’t know where to begin or where to focus to improve value delivered and the contribution of the portfolio to strategic goals. Two things that can help are Taxonomy and a Landscape Health Assessment.

Taxonomy is a common architecture technique where we use a set of categories (usually capability or functional) to organise the baseline applications so that we can detect redundancy (multiple things doing the same job), gaps (where we do not have something or the current solution is not adequate) and opportunities (where there is something useful but it is not widely deployed; or there is an easy “off the shelf” solution for a gap). A good starting Taxonomy can often be obtained as an industry or domain reference model.

A Maturity Model is less common. In fact, several years ago we were doing a consulting assignment and looked in vain for a “maturity model” or “portfolio review model” for the application landscape. In the end we created one which we have used since. I recently revised this to include guidance based upon findings (as we have for other models including our Data Management Maturity Model) and we have automated it on our Maturity Model Platform, in turn based upon our Enterprise Value Architect tooling.

This provides a quick, guided, automated way to move from little knowledge to a robust view on the application portfolio status; scores on several important health dimensions; and recommendations of actions to improve the health of the portfolio and value delivery to the business. The instrument also looks at strategic issues and leveraging technology. For a limited time, you can try it free. You can save results, retrieve them in future and compare them over time or scenarios.

Take the Application Landscape Assessment

We welcome feedback and further questions.

If you are keen to build Application and Solution Architecture Skills, consider our Techniques and Deliverables of Application and Solution Architecture online live 5 day course (31 Oct - 4 Nov).

You can read the full details or enrol here.

Zero CRUD* with Domain Models and Patterns

Many organisations still have armies of developers grinding away writing Create, Read, Update, Delete (*CRUD), enquire and report user interfaces and business logic - even in “Agile” projects! With a complex domain model, it can easily consume more than 60% of project effort. Indeed, some administrative systems are nearly 100% CRUD!

One solution is to resort to low-code or no-code tools, but organisations resist them for a variety of reasons, including lack of standards, limited skill availability, strategic risk and the fact that many of these only work well in narrow use cases.

It is really important in stakeholder facing applications and websites to have really good user interfaces, so what to do? One solution we have practiced for over two decades, and adapted for the web and mobile, is to have a domain driven user interface which exploits patterns for the commonly required functions.

Patterns consist of UI code templates which provide layout, controls and common business logic. They have placeholders where the specifics of the entity / concept to be captured, edited, updated or deleted etc. are plugged in. The domain specifics (Concepts, Relationships, Properties) are provided to the application as models which are accessible at generation or run time.

For statically bound environments (e.g. C++, Java, C# etc.) the customisation of a pattern with domain specifics can be done at compile time. In effect many interfaces conforming to the pattern are generated into the production application. For dynamically bound environments (e.g. Smalltalk, Python, JavaScript) the generation can even be done at runtime, effectively serving the code to the client where it will execute through interpretation.

This approach has numerous advantages, including:

  • Major reductions in code base size and hence effort in development and maintenance

  • Consistency of user interface and logic produced across developers and applications

  • Higher quality since the patterns can be developed by expert developers and thoroughly tested

  • Reduced time to market and greater agility. In the case of late bound environments it is even possible to extend the domain model at runtime and have the interface adapt immediately without any deployment

  • Massive reductions in effort when user interface refreshes are required (e.g. the latest / greatest JavaScript framework makes a new style “required”)

If you would like to see a talk and demonstration of this in action, you can watch the video here.

If you would like to skill up on the latest in Application and Solution Architecture thinking, take a look at our upcoming course: Techniques and Deliverables of Application and Solution Architecture.

#agile #SolutionArchitecture #DomainDriven #SoftwareDesign #Patterns

Context is Worth 60 IQ Points

This quote is attributed to one of our favourite great thinkers, Alan Kay, founder of Object Orientation, Graphical User Interfaces and other major innovations. We believe it applies to Business Architecture in a major way.

Most Business Architecture methods/approaches/languages (TOGAF®, BizBok, Archimate®...) originated from an Information Systems/Technology perspective. This is reflected in their view of concepts relevant to the business, which typically include: Organisation (Actor, Role), Process, Service, Capability, Motivation (Driver, Goals, Objective), Metric, Function and Contract. In their latest incarnations they may also recognise Value Chains and Course of Action. The former does relate to the position of the organisation in its industry, while the latter relates to high level change/initiatives.

What is typically missing, in our view, is consideration of the context in which we operate in a serious way. The context includes: Competitors, Product and Service Offerings, Legal and Compliance Environment, Technology, Political Climate, Society, Various Stakeholder Groups (Customers, Agents, Suppliers, Channels, Business Partners, Unions, Regulators, Industry Bodies…) and the Value we exchange with them, the Economy, Resources, Ecology, etc. all of which can provide Opportunities and Threats.

A thorough approach should contemplate these issues. There is no point designing a great new internal combustion engine vehicle in a world where legislation and public sentiment will prevent us selling it. There is no point devising a strategy where there are no resources to realise it. There is no point launching a physical record company into a media space that has gone fully digital (unless we want to be a niche player).

Being fully cognisant of our context helps us be much more intelligent about our strategy, our architecture and the resultant initiatives.

TOGAF® and Archimate® are Registered Trademarks of The Open Group. BizBok is a publication of the Business Architecture Guild.

How to measure business capability improvement objectively after transformational projects have been implemented?

I recently had a delegate on our Business Architecture Mastery Programme ask the above. It is a deep question with a number of dimensions. We have some ideas and a bit of experience...

Capability

First, we have a different take on what a Capability means. Most methods define it a bit fuzzily as "something a business can do" or similar. That is not too different from a Business Function. They use Capability so people don't get confused with Functions used in Organisation Design, which might refer to “HR” or “Finance”.

We think a Capability implies quite a bit more. It implies delivering something of value to a client (potentially internal). There is much more detail in an earlier post. See comments for link.

Motivation

When we want to start discussing improvement, we then also need to think about motivation. What do we want to change (improve), why and how? These motivations could come from a number of sources and will be different for various stakeholders. We need to find a way to merge them and reach consensus on what "improvement" means. Please see the blog entry for a view on merging motivations (link in comments)

Metrics

Once we understand what we value and how it should be improved, we then need suitable metrics. These will depend upon the agreed goals. One stakeholder group (eg investors via the stock exchange) may only be interested in financial performance this quarter. Another stakeholder group (say employees) will be interested in job security. Another group (the community) will want to be assured that we have improved our environmental footprint, etc.

There are a variety of ways we can measure a business, its performance and its health, including traditional financial measures, balanced scorecards, customer satisfaction, sustainability metrics, strategic health checks, maturity models and industry metrics frameworks, etc.

Baseline

Next we need to know the baseline we are improving from. That involves gathering the facts for the chosen metrics via a variety of methods including accounting, scorecards, business intelligence, survey, workshop, etc.

Run the Initiatives

Finally, we can the implement our changes and then measure again.

Tracking

For tracking, we like to use a hierarchical model proceeding through layers of mission/goals/objectives which we then colour code based upon current performance (red for poor to green for excellent). This give a visual "heat map" of where to focus attention. Put it on a wall! Then measure again in about 3-6 months, depending upon the volatility of your industry. Using the new measures, update the colour coded model. Of course, also update the model itself with new concerns, insights and learning.

#capability #improvement #metrics #businessarchitecture

Product Generator (3 of 3)

In the earlier posts we covered what a product/service/business model innovation might look like and how to generate ideas. Here we summarise general guidelines we can leverage when contemplating product and service options:

  • Does it provide a recognisable and desired transformation?

  • Does it offer exceptional client value?

  • Is it easy and convenient to find, evaluate, acquire, migrate to, use, integrate, upgrade?

  • Does it generate an emotional response in the client?

  • Is it a blue ocean play that will encounter minimum competition and still attract a premium price?

  • Can it be sustainably and profitably offered at scale?

  • Have we used all options to reduce capital dependency, to minimise physical components, increase intelligence/utility and to streamline production, duplication, delivery and servicing?

  • Is it a win for the customer, us, suppliers and society at large?

  • Have we contemplated constraints and risks and ameliorated these as much as possible?

  • Have we created unique benefits which will be difficult to replicate?

  • Is there a “unique selling proposition” / “purple cow” - i.e. will it stand out as something different and worth consideration?

  • Have we formulated metrics to track performance and improve benefits through the lifecycle?

Getting there may not be a linear path. We may have to ideate, evaluate, prototype, iterate, pivot, etc. until we get it right.

Summary: Provide more value to customers, more conveniently, quickly, cheaply, sustainably and repeatedly (while ensuring we can sustain delivery, margin and ameliorate risks). The associated canvas may help to consider all the dimensions.

#Product #Service #Strategy #Innovation #BusinessArchitecture #EnterpriseArchitecture #Canvas

Product Generator (2 of 3)

So how do we find great product and service ideas? By thinking in the box, at the boundaries, out of the box and beyond!

Explore the idea of the “adjacent possible”, looking for opportunities enabled by emerging technologies, services, social and other changes, that are now just possible and satisfy an existing need in a new way. Examples were the miniaturisation of disk drives facilitating the idea of mobile digital music players and of pervasive internet and mobile technology facilitating music streaming. Also Software as a Service (SaaS) offerings exploiting the availability of networks, cloud platforms and subscription models. Machine Learning is opening up opportunities in medical analysis. Speech assistants are enabling new kinds of interfaces to electronic products.

Seek “blue ocean” opportunities. Instead of competing fiercely in saturated, highly competitive spaces (the “red ocean”), we look for opportunities which satisfy a need in a new and novel way, where there is currently no or very little competition. An example would be early products delivering voice telephony over digital channels (voice over IP or VOIP). Tesla has famously exploited this kind of approach in bringing fully electric cars to consumers.

Exploit digital. Make products “softer”, replacing expensive hardware with software or data: replacing atoms with bits. Make copies electronically rather than through manufacturing. Hold inventory as patterns of bits which can be duplicated and distributed with almost zero cost. Automate processes, so they can scale without extra staff or effort.

Consider the portfolio view of products and services and where they are in their lifecycle and adoption. Ensure balance across the stages.

Try to launch and get feedback as quickly as possible. Build prototypes and get rapid feedback. Explore Design Thinking to really understand the customer requirements. Build a Minimum Viable Product (MVP) and get customer feedback. Pivot where necessary.

Look for platform plays or intermediary roles. Own the customer and transaction and make a margin, without needing to own the assets or physically deliver the service. Most of the exponential businesses that have exploded in the last decade exploited these ideas. Consider Facebook which facilitates messaging, but produces no content; Youtube which is a major entertainment provider, but owns and creates no content. Amazon is a platform and an aggregator, selling millions of products from thousands of suppliers.

Consider innovative business models that satisfy the same need in a different and better way. A customer may really want personal mobility, not necessarily a car, or ambient music delivered on demand, rather than a sound system. Here it is often useful to “abstract up” asking the questions: What does this achieve for the customer? Why does the customer buy this product/service?

#Strategy #Product #EnterpriseArchitecture #BusinessArchitecture #Innovation

Product Generator (1 of 3)

What does a great product look like in 2022? Actually, it’s not a product, but a service or a platform or a model! Or maybe even a feeling...

Whaaat? Yep.

The truth is that people don’t buy products. They buy some transformation that they want. I want my feet to stop hurting, I buy shoes. I want my children to have a better life, I buy an education annuity. I want to satisfy my craving, I buy chocolate. I want to impress my partner, I buy a great outfit.

Transformations are as easily satisfied by a service, platform, model, algorithm or design as by an actual product. My desire might be to enjoy a particular genre of music. This could be satisfied by (a) buying a CD (b) buying a track on iTunes (c) streaming audio from Spotify. If I need holiday accommodation, I can use a hotel, Booking.com or AirBnB. Interestingly, iTunes, Spotify, Booking.com and AirBnB are all platforms. They do not own the assets or services on sale, but they facilitate the client’s access to them while also acting as channels for the sellers. In the case of iTunes and Spotify, notice too that the product has also become digital - morphing from physical media to digital streams. These models allow taking advantage of the “long tail” phenomenon whereby the cost of inventory and distribution becomes near zero and the platform can offer essentially infinite variety and choice.

Client experience and emotion also play a large role. When you buy a property (a major financial, long term commitment), you will probably make a very logical checklist of requirements before going to view any properties. But you will buy one which doesn’t meet the requirements, because it “felt right” or “smelt right” or “had great light”. We will then go back to the list and adjust and reprioritise until it fits our choice… Brands like Apple and Nike know this all too well. They invest huge effort in building the lifestyle image, client experience and emotional highs their clients will experience from using their products and services.

New value today is potentially delivered “out of thin air” - think of a virtual product such as Bitcoin, which is essentially an algorithm for calculating a number. Yet it has become a major asset class with serious investment houses putting 5% of their assets into it and similar offerings in 2022. Other examples are an algorithm that improves fuel consumption in transportation, or a model for how to organise components on a semiconductor die.

Modern consumers are also used to instant gratification, based on experience of mobile technology, apps and streaming. We need to ensure that our product/service is very easy to find, evaluate, try out, purchase and use. This should be as friction- and noiseless as possible.

In the second part of this post, we will explore how to come up with and evaluate product/service ideas.

#Product #Innovation #Strategy #BusinessArchitecture #Service

Unifying Motivation

It’s pretty standard to consider Mission, Goals and Objectives when doing a business architecture. Some use functional decomposition to increase the rigour of ensuring that these are aligned. Maybe we draft a Vision - a shared and inspiring description of a desirable future state. But what of the other reasons we do things? From traditional SWOT analysis come the Strengths we want to capitalise on, the Weaknesses we want to eliminate, the Opportunities we want to exploit and the Threats that we should minimise.

Once we start to bring in outside factors, such as threats and opportunities, we may as well get more comprehensive and look at STEEPLED analysis: Social, Technology, Economic, Environmental, Political, Legislative, Ethical and Demographic factors that may influence plans and actions. Social change may involve nuclear versus extended families; urbanisation, unemployment, etc. Environment factors may mean dwindling resources, avoiding pollution, or creating circular business models. Political factors may dictate which products are viable in a given market. Legislation may require compliance, restrict services we can offer, or dictate hiring policies. Ethics may dictate that we change business practices. Demographic changes, such as an ageing and better educated population, may affect product design.

We can add the concept of Drivers (which overlaps with the preceding), looking for factors that require us to change. Examples include: Competition, Cost or other ratios, Technologies important in our industry, Values and Ethos of the business, etc.

If we analyse capabilities (possibly within value chains / networks / streams), and have a clear vision / mission / goals, then we can also do a Gap Analysis of what is missing to get there. Addressing capability gaps generates clear goals and potentially, initiatives to address them.

Another dimension is our Product and Services portfolio. Which ones are profitable? Which ones are where in their lifecycle? Which ones are sustainable? Which fit best with the contextual analysis we have done? What becomes possible with new technologies, design thinking or innovative business models?

Finally, we can also do a Business Health check (a multi-dimensional review taking in many strategic dimensions including: strategy, management, architecture, human resources, assets and liabilities, profitability, cash flow, return on investment, geographic coverage, shareholding, partnerships, channels, information use, risk management, agility, etc. ) or at least a Balanced Scorecard.

All of the above can be integrated into a coherent Motivation Model. This should be constructed to be compliant with our Business and Architecture Principles which guide what we will and will not do and how we will go about achieving it.

Why do we need to change? What does a desirable future look like? What needs to change? How can we go about it?

#Strategy #Motivation #BusinessArchitecture #EnterpriseArchitecture

Positioning Business Architecture

Popular Enterprise Architecture methods position Enterprise Architecture, including Business Architecture, within I.T. and reporting to the CIO or CTO. This reflects the history of how EA methods have arisen: initially addressing Technology, then Applications and Data. As I.T. became more strategic and vital to business and businesses realised they needed alignment with I.T., management of costs and risks, the Business Architecture domain was added or expanded.

For most current EA methods, this is very much I.T. looking at the business to understand the organisation structure, processes and (maybe) value chains and capabilities which I.T. should enable and support. This may be OK for Enterprise I.T. Architecture, but is not true Business Architecture. The latter should be architecting the business and its future within the context where it operates. Given this perspective, Business Architecture should be outside of I.T., possibly in a Strategy or Business Change area. It should report to the Chief Strategy/Change/Executive/Operations Officer. Some advanced organisations now have a Chief Architect at ExCo level, responsible for all aspects of change and future planning.

The danger if Business Architecture reports to I.T. is that the agenda and priorities will be driven from this perspective. We watched this happen in a client organisation. They had a fairly new but competent Business Architecture function which was working well and initiating and guiding strategic change. The I.T. function was not performing as well and they hired a new high powered CIO to take that over. He lobbied hard and was successful in bringing the Business Architecture function under his control. Within two years it had lost all effectiveness as an agent of strategic business change.

By contrast we assisted another client to establish an EA function, and a Business Architecture competency from scratch. The Business Architecture function reported directly to the Office of the CEO, who was also its sponsor. A PMO was set up to drive the change projects, and the triumvirate of Business Architecture, PMO and IT (Including Enterprise I.T. Architecture) proved highly effective in driving a major strategic transformation programme including many non-I.T. aspects over a period of three years (and ongoing).

The diagram indicates how pivotal a good Business Architecture function can be. It informs the other architectures below it to ensure alignment. It drives business initiatives, which deliver competencies to operate the business.

The picture, of a lookout post in Israel, is a bit more tongue in cheek. It illustrates the current position of many Business Architecture functions - high up, but precarious!