Solution Architecture and Application Architecture

Enterprise Application Architecture = Solution Architecture?

Steve Armstrong • Enterprise Architects frequently refer to different domains such as Business, Data, Technology, Solution, and occasionally Application. I’d like some input on the differences between an Application domain and a Solution domain. My sense is that for many the Application domain refers to the higher levels of the technology stack (eg: models, principles and patterns for Process, Views, and Services) which should of course should be modeled based on the business domain. Conversely, the Solution domain seems to represent architecture guidance that brings together all the domains to deliver an operational system / “application”.

TOGAF v9 for example defines an Application Domain that is part of the “Information System Architecture” (along with Data). It’s only reference to Solution Architecture is in the definition section… it’s not a core part of the ADM. Presumably “Solutions Architecture” would occur as part of phases E – G (Opportunities, Migration Planning, and Implementation Governance).

So, in a holistic EA practice (for a large enterprise), is it appropriate to have both an “Application” and a “Solution” Domain, or are they roughly the same thing? My belief is that they are different, and that both are probably needed… Application to give much needed guidance on Process, Views, and Services, whereas Solution Architecture needs to deliver models, principles and patterns that help to unify business, technology, and data architecture guidance into a working SDLC.


Sam Waissman • I have seen a common misconception in both business and IT where “problem=application”. We in IT have been operating in such model for so long that it is easy to jump to the conclusion that “application=solution”, plus or minus the required infrastructure and data (depending on the organization’s maturity).

I see solution as the larger context in which the technical and non technical components are connected to support/realize the business strategy. Solution often describes in Business terms how the business strategy is broken down into business capabilities, their enabling processes and last, the associated automation. Not all Solutions require automation (technology).

Solution Architecture is what is presented to the business. In my experience, the underlying domains (app, data and technology) have a different audience. I’m not minimizing the value of all the layers, but if we make an analogy to construction, we would see from the architect all the plans and layout, but maybe the conversation about the pipelines would be brief.

Gopal Panchavati • IMO, in simple terms, an application is a tangible, physical outcome of a solution. You present a solution to the business users, and when everybody agrees, you deliver application(s) which support the solution. I agree with Sam that not every solution ought to involve automation/technology/application. A solution to a business problem could be a simple change in the business strategy or a process change. My 2 cents.

Steve Hudson • Application and Solution architecture are vastly different. I equate an Application architect to a Software architect. An application architect knows how to structure software based on the runtime platform the software is being built so as to increase the architectural quality of the code (e.g., encapsulation, high cohesion, loose coupling, etc…). A Solution architect should be far less concerned with the technologies that will be used to build and implement the solution. They are far more concerned with the Business concerns, such process improvement. They understand the need of the business rather than the mechanics of technology. An Application architect is trying to optimized the use of technologies to implement a solution. A Solution architect is trying to optimize the business benefit of investing in a solution.

Neil Brown • Sam Waissman wrote : “not all Solutions require automation (technology)” Amen to this, Sam!

I always say “a solution will involve process change, and may involve technology.” Our business colleagues want ‘solutions’ after all, so that’s where we should focus our attention. infact the only stakeholder group who seem consistently keen on an ‘application’ being the answer to life the universe and everything – are vendors.

Let’s designate the term “application architect” as ‘defunct’ – and vow to spend more time considering non-technology solutions in the new year!

John Pflugrath • Does Application Architecture = Solution Architecture? No.

In my mind, Solution Architecture takes looks at the overall problem and works with other experts to build the best possible solution that will work in the real world from those other available parts. Often, applications are not directly part of the solution.

Application Architecture has almost exclusively been used for software architecture in my experience. The level of expertise needed to be a competent software/application architect usually prevents those practitioners from gaining expertise in systems architecture or enterprise architecture because they need to be extremely well versed in software design and construction.

Enterprise Architecture is an ideal situation and rarely achieved. There are always parts of an enterprise that cannot follow the “golden enterprise architecture” completely.

Solution Architecture attempts to make gains on the ideal enterprise architecture roadmap and understands the application architecture for the multitude of apps involved to build a workable solution. Along the way, a solution architect must understand the capabilities (and limitations) of network, storage, data, and enterprise architectures so the final designed solution can actually work for the business client.They must also understand the business and people aspects to realize that overly complex solutions cannot be performed by many thousands of people day after day without mistakes. *Knowing what works and what doesn’t in the real world is key.* Solution Architects are where the Business, People, App and IT rubber meets the road and where the amount of dirt and sand kicked up going down that road is minimized.

I’ve seen where IT and Business concerns clashed and had to explain to the business why using a specific solution was a really bad idea. The business decided to ignore my recommendations and deployed their solution to 1200+ locations and 20K workers. It was bad then and it is still bad today. The plan was to save time and complexity for 20K workers, but it ended up adding significant complexity for all of them and internal help desks to support those workers. The deployed solution was at least 10x cheaper than my recommendation, but continues to cost the business much, much more than that in people-time every day.

Steve Armstrong • Thanks for the feedback guys. In my original post, I should have clarified my view that output from the Solution domain may ultimately drive the delivery an “application”, via the Application Domain. Forum feedback is validating what I believed to be true and giving a bit more insight into how to structure an effective EA model and practice.

I’m definitely seeing a lack of clarity in the use of the term “Solution Architecture”, with an assumption that Solutions generally equate to Applications. Unless I’m reading it wrong, it certainly doesn’t help clarity when “EA Frameworks” such as TOGAF define Application Architecture as “A description of the logical grouping of capabilities that manage data objects…”. On the one hand it’s definition and it’s presence as a core element of the framework suggests that it’s aligned with Solution Architecture, while it’s name uses the word “Application” that is commonly associated with an physical assembly of technology components.

Neil Brown • Steve, the term ‘solution’ was deliberately chosen because it is independent of what a solution might comprise. So ‘Solution’ doesnt equate to ‘Application’ architecture in the circles in which I oscilate, although I do hear confusion out there in all these titles.

SW may form a part of a whole solution – and I might employ an SW architect/ designer to flesh out that component, just as I might employ a process designer). Yes,you hear this role sometimes referred to as ‘application architect’ – but to me its not a helpful title with semantic/ role overlaps all over the shop.

The word ‘application’ has long been a term looking unsuccessfully for a common definition. I stopped using it a decade ago. TOGAF, bless it’s extremely overblown socks, tries hard to seal the deal, but the water was already irreparably muddied by vendors and recruiters alike.

So to summarise – dont agree there is a lack of clarity with the term Solution architectire. Its application architecture that has the problem. This said – if you dont like ambiguity – you are in the wrong job!

Ian Glossop • No.

Solutions are solutions to business problems which may or may not involve software. It is a bad assumption that the solution to every business problem is a bit of software – an application. That is the worst form of ‘application centrism’ – and is common in the IT industry.

If, and it is a big if, an application (software) is involved in the solution at all, it may be a small part of the solution – it will never be the whole of the solution and may not even be the major component.

If, and it is another big if, it makes sense to build an application rather than buy it then you might need (to create) an application architecture (description). [You always need to understand the application architecture – but most of the time you should just buy that understanding in the form of models from the software vendor along with the software itself].

Steve Hudson • Do you REALLY need to know the architecture of a bought application? If you do, then I would question if you should have bought it to begin with.

Ian Glossop • Depends what you mean by “architecture” really.

I would assert you need to know the large-scale partitioning of functionality in the application, how centralised / decentralised it is, what the infrastructure and communications demands and interfaces are, what services the software automates and what technical capabilities it delivers, which of your enterprises’ data/information elements are processed or used by the software and how, and the topological location and nature of the software and human interfaces.

That is, the external or exogenous, outside perspective of the application’s architecture.

You need to know this stuff – and often vendor documentation is sadly lacking and you have to get this knowledge from practical experience with the software – in order to build effective sociotechnical systems, business processes and organisational capabilities around the software – or assess its fit to top-down design of same.

As to the internal design and construction of the application, yes you are right – don’t need to know and don’t really care.

[Except you need to know it is amenable to change with the minimum of effort and investment over a 5 year timescale – you need to know to what extent it is designed for flexibility and whether that fits in with the enterprise’s plans for change].

Lawrence McCaskill • In DoDAF parlance, the solution architecture is the answer to the requirement documented as a capability, elaborated upon within the operational views, and fully functionally allocated in systems/services views.

Application architecture is at a lower level of abstraction. It is particular to a system.

Ian Gardiner-Smith • My thoughts

  • Application – architecture concerned with internal composition of an individual application.
  • Solution – Architecture concerned with a complete business solution may use less than 1 to many applications.
  • Domain – architecture concerned with a specific business domain (eg finance or insurance claims) or technology domain (eg data warehouse ).

Mark Davis • Sadly, there isn’t a standard for these terms. Meaning follows the chosen method. Founding an architecture practice requires a specific task to clarify basic terminology regarding solution, application, domain, etc. Most of us take the “efficient” approach of adopting a particular method and adapting it to our specific context. Part of that adaptation is to color the language in light of the type of enterprise. The last problem we face is communicating with other architects in other contexts. The general concepts we’re describing are common to us all, but the names are fluid, which can result in some confusion. That’s unfortunate.

Andre Dutra • As pointed out above, there is significant confusion on the use of the terms application and solution, which means different meanings and interpretations are used. An architecture practice has to clearly define how it interprets them to be effective. My own definitions go in the direction below.

For application architecture, I tend follow the TOGAF definition, which means is one of the four domains of an enterprise architecture (business, information, application and technology).

For solution architecture, I see it as more tactical kind of architecture, which respond to a very specific, more immediate subset of business problems or goals of an enterprise. In this sense a solution architecture would usually refer to one step that is part of a strategic roadmap defined by an enterprise architecture.

Considering these interpretations, it follows that a solution architecture is not a domain in the sense of application architecture. In fact, a solution architecture may encompass other domains than just the application architecture domain. On the other hand, application architecture would have different scopes if considered as part of a enterprise architecture or a solution architecture.

I would also not consider application architecture the same as software architeture. The definition of the application architecture in either enterprise or solution architecture contexts would be in a higher level than the software architecture. The solution architecture would go as far as it is required to make a buy or build decision, keeping the consistency to the other domains, and the software architecture itself would be more related to the build.

Ian Glossop • @Andre

There are at least two interpretations of the term “Application Architecture”. One is the architecture of an individual application (whatever that might mean). Another is the architecture of the portfolio of applications that spans the enterprise. TOGAF I would argue confuses at least these two meanings (and possibly others) – which means to say the manual uses both meanings in different places without being clear about which meaning is intended.

I would argue the first is not much to do with Enterprise Architecture and the second is a small but very significant part (being part of the IS architecture a la TOGAF ADM phase C).

Otherwise I would agree with you, a “solution” is a thin, narrow-scope, contextual slice across all the TOGAF ‘domains’ – not just IS and certainly not just the ‘Application’. Sections 20.2 and 20.3 of the manual kind of allude to this but don’t make a great job of explaining it. People often confuse ‘levels’ with domains (both those words are well overloaded and ambiguous as well as ‘application’).

Ravindra Maurya • IMO the definition pointed out by Lawrence with reference to DoDAF “the solution architecture is the answer to the requirement documented as a capability, elaborated upon within the operational views, and fully functionally allocated in systems/services views” is an adequate definition of Solution Architecture without demarcating it in boundaries of IT or non-IT solutions.
Application Architecture then further complements the adopted solution architecture by defining an application framework (again IT or non IT) and laying out a blueprint to implement the solution on ground (to bring in effect).

Richard Jones • For me, Solutions solve a problem; they encompass business processes as well as applications. Applications may or may not form a part of Solution.

Paul Preiss • As you have seen from the posts there is no universal answer to your question. Most architect and architecture related questions have different answers based on organization, background and opinion of the individual answering. This was one reason we started Iasa in the first place. There is good news however.

Our research indicates a number of different elements you should consider based on what you are trying to accomplish.

  1. Are you working on AN architecture in the sense of a deliverable or template for deliverables (in the sense of document)?
  2. Are you concerned with role definitions in terms of the skills or level of an application vs a solution architect?
  3. Are you concerned with communicating effectively internally or externally to the architecture team?

These axis give a slightly different perspective based on statistics we’ve gathered from architect surveys and numerous team reviews. Both anecdotal and object evidence suggests that the primary difference between the terms for all three axis is related to architectural scope and context. In general a solution architecture and architects is perceived as being high in scope of impact or including more elements/projects.

Luis Anaya • I think that a lot of folks already answer the question on solution vs application. Keep in mind that part of a solution involves other aspects like…

  1. Methods and Procedures (what to do what, when).
  2. Roles and Responsibility (who operates, who troubleshoots, who coordinates).
  3. Solution Roadmap Management, Release coordination (what features when, what other applications are incorporated, when).

There might be others, but those are the ones that come to mind.

Hope this helps.

Average rating / 5. Vote count:

No votes so far! Be the first to rate this post.