Please state your position Photo: BNThermic via Police Helicopter, 14 March 2014

Please state your position
Photo: BNThermic via Police Helicopter, 14 March 2014

“What’s the difference between APIs and SOA?” A question with a million answers.

I’m not going to tell you I’m the holder of the One True Way here. I’m going to give you the Smart421 position.

To us, SOA was always about delivering easy to understand interfaces that expose business functionality from diverse underlying systems. We always felt this was as much about people as technology, and we never particularly bought into all the vendor hype that demanded true SOA required a massive stack of complicated tools and technologies, that (what a co-incidence!) only Vendor X could provide.

We’re simple straightforward folk, who like simple straightforward solutions.

Let’s take registries and repositories as an example. I once said to a colleague that one vendor’s product looked like it was designed by machines, for machines. It used language like Port Types, Bindings, Metadata, Ontologies etc. It was the dream of people who like to put acronyms on their CVs. What it didn’t help with at all from what I could see is helping the developers throughout your organisation discover services, and really understand quickly and easily what the service did, and how to use it.

The API movement has, by necessity, stripped a lot of the complexity away. Why? Because it turns out that if you are going to expose APIs to the outside world, where people have a choice about whether they should use your API or someone else’s, ease of use, and ease of discovery are critically important characteristics. Integrating with a REST(ish) API is, frankly, easier than integrating with a SOAP service. Discovering services and understanding them on a developer portal that is designed for humans is easier than poring over piles of WSDL in a freakishly complicated registry product.

If you’ve wondered why truly successful SOA initiatives are common as unicorns, here’s why: They often overcomplicate everything. Technology, processes, standards and the services themselves become a barrier to the very innovation they set out to enable.

Of course, nobody mandated SOAs have to be complicated. Nobody forced the world to adopt WS-*. We often tried to encourage customers to delay adopting complexity until the last responsible moment. That’s not to say WS-* weren’t useful. In the right contexts, they were, but they often came at the expense of accessibility and increased friction in adoption.

Unfortunately, the brutal reality is that for most people (or at least those who commission such initiatives), SOA as a term is connected indelibly with SOAP, ESBs, WS-* and rigid over-engineered change processes.

Sometimes, beautiful relationships don’t work out. Sometimes you just have to move on. So we have.

For us, APIs are the new SOA. What you might call SOA, we will refer to simply as internal APIs. On one level, this doesn’t change anything – it’s an emphasis thing. We still believe in the principles that underly SOA, and we’ll continue to build our integration on this basis. We know that APIs aren’t a silver bullet either. We’re certainly not saying “As long as it’s an API it’s good, and any old API will do”. There’s still plenty of scope to fail, plenty of mistakes to make (and to avoid repeating), and plenty of learning to do for our customers, for us, and for the entire API ecosystem.

But whether internal or external, we’ll focus on the same thing: Crafting APIs that are beautifully easy to understand, consume and change. We’ll fight the good fight to keep the standards and technologies we use mercifully simple, lest APIs suffer the same fate as SOA. We’ll try wherever possible to make the technology fade into the background.

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Antoine de Saint-Exupéry

Share this post using the social icons below or via the short URL

Please Rate and Like this Blog. Our Readers want to know what YOU think so please Comment.

Photo: Industrial backdrop by Pilarts  Dreamstime Stock Photos & Stock Free Images

Photo: Industrial backdrop by Pilarts Dreamstime Stock Photos & Stock Free Images

I’d like to propose a best practice for rolling out new features in a Service Oriented Architecture (SOA).

Traditionally, when we roll out a major new feature, we often end up causing a breaking change to the service. We’re then faced with a choice: (a) Force all our consumers to upgrade to the new version, and making all our consumers hate us, or (b) continue to support the old version of the service as well as the new, making only our own teams hate us. Suck it up, plan (b) is the better option, but try telling that to the guy having to patch fixes in three concurrent versions of a service.

Now, there are patterns that can help here (more on that another day), but they all still mean more work for everyone.

Also, when we first roll out a feature is exactly the moment we understand it least. We’ve got absolutely no idea how people will use it, nor whether it will even turn out to be useful. By baking the feature into a new major version of the service, we’re taking all our options away. The feature will be hard to remove if we decide it isn’t useful, and if we want to change how it works, we’re back into a major version upgrade again.

To my mind, good engineering is largely about keeping your options open. It’d be nice if we can try a new feature with a subset of consumers first, iterating quickly with just that subset, gradually adding more consumers as we get more confident.

Enter the Feature Flags pattern. Feature flags allow you to turn features on an off at a moment’s notice. At its most basic, a feature flag just turns a feature on or off for everyone at once, but the idea is often extended to allow turning on features for specific users, or collections of users. This allows you to roll out a new feature to consumers gradually, over an extended period.

So, here’s the proposal:

  • Allow consumers to pass a set of feature flags dictating which features they’d like enabled in the service.
  • Whenever you build a major new feature that would otherwise cause a breaking change, only enable it when the feature flag is passed.
  • If appropriate to your environment, control access to feature flags like you would to any other resource – e.g. you might want to restrict access in the early days to just a single consumer, making it easier to iterate.
  • Once we’re comfortable with a feature, it becomes publicly available – i.e. anyone can toggle the flag.
  • Every so often (e.g. once every couple of years), create a new major version of the service, refactoring it to include popular, battle tested features by default. Also, take this as an opportunity to clean out the cupboard and abandon any features that aren’t well used.

What do you think? Comments and thoughts very welcome…


Please remember to Rate and Like this post.  If you can, please leave a Comment.

What is the OTA?

The OpenTravel Alliance provides a community where companies in the electronic distribution supply chain work together to create an accepted structure for electronic messages, enabling suppliers and distributors to speak the same interoperability language, trading partner to trading partner.

What does the OTA look like?

A set of XML schemas (XSDs) that define travel-related entities organised into common and domain-specific types. Domains include Air, Rail, Hotel, Vehicle, Insurance, Cruise. AirPriceRS example below (from XMLSpy):


OTA Pros?

  • Off-the-shelf extensible set of components developed by the travel industry that can save valuable time and effort when designing your XML message structures.
  • Provides a common vocabulary.
  • Helps towards developing a canonical schema/data model .
  • The OTA is updated twice a year, and all schemas are backwardly compatible.
  • Maximum flexibility – all elements and attributes are optional which allows companies to choose which parts they want to use.
  • Enables companies to derive maximum value from legacy systems by wrapping them in a service façade.

OTA Cons?

  • Provider systems may only support subsets of the OTA.
  • Companies often have their own internal vocabulary for OTA entities – mapping from one to the other can be confusing.
  • Bespoke schemas will still be required. However, XML namespaces allow OTA and bespoke vocabularies to be used side-by-side.
  • If you make any custom extensions to the OTA, these will be lost when moving to a new OTA version.
  • The flexibility of OTA entities can sometimes result in unwieldy messages.

Why use the OTA?

The choice of whether to use the OTA or a bespoke solution will ultimately depend on how applicable the OTA is for a specific travel sector and the take-up of OTA by provider systems in that sector. Smart421’s experience of working with Virgin Atlantic to develop their SOA offering is that using the OTA is beneficial.


Please Rate and Like this blog.  If you can, please leave a Comment.

Ipswich from the air

Ipswich from the air. Photo by kind permission of Stu Smith. More at

 One of our more intrepid colleagues, Smart421 lead consultant Stu Smith, has just published some outstanding aerial photos of Ipswich.

When he’s not architecting IT systems, configuring IBM DataPower appliances behind closed doors in a customer’s data centre or speaking at industry events (e.g. WUG), Stu is often flying the skies of urban or suburban areas with his paramotor or paragliding over more inhospitable terrains somewhere in the world.

His latest views of Ipswich, taken in August, can be found here

Those familiar with the area will easily spot the Smart421 technical centre at Felaw Maltings, as well as Portman Road (home of Ipswich Town Football Club).

Leave a comment to tell us what other landmarks you can see.

Neil Miles (second from left) with Jennifer Davidson of Gartner events

Neil Miles (second from left) with Jennifer Davidson and Heenal Taylor of Gartner events

Now that we’re are no longer Gartner “virgins”, this post covers Smart421′s second only event with Gartner, their Application Architecture, Development and Integration Summit in London on 16-17 June (Twitter hashtag #gartneraadi).

We learned a lot about working with Gartner at our first one, the Enterprise Architecture Summit last month (see previous post).

For us, Getting Gartnered is an unfolding story and not self-evident; analyst relations is one part of the equation, and working with event audiences another. We don’t see this as a “one night stand” – it’s more like “going steady”.

We’re getting to know the way that Gartner does things and learning a lot of lessons in the hope that we can get closer. If it is to succeed and develop in to a long term relationship, then clearly 50/50 will never cut it – so it has to be 100% from both sides.

Joseph Spearpreparing to go on camera

Joseph Spear, marketing manager at Smart421, preparing to go on camera in a TV interview to explain Smart421's growing relationship with Gartner

Smart421 is investing in analyst relations because we recognise the power of the Gartner brand. Their analysts are well briefed people who are focused on providing their research clients with insight far beyond what’s available elsewhere. We have seen this in action at our parent company, KCOM Group, which is itself a research client. We also recognise the significance to the IT industry of their analysts’ reports and various presentation methodologies (Magic Quadrant, Hype Cycle, etc). But the rubber hits the road for us where Smart421′s customers are using Gartner research notes and consulting, etc. to help guide their strategic decisions.

We want our existing Customers to see us mentioned in research that matters to them and we think that our future customers will also reasonably expect this. We realise that we have no exposure today in Gartner research so our senior management team have agreed to act on this. Robin Meehan, Smart421′s chief technology officer, is leading this effort. Although it’s early days, I’m encouragd by all that Robin has already achieved with his three separate Vendor Briefings on Enterprise Architecture, on Cloud Computing and on SOA, in advance of the events as well as holding Analyst 1:1 sessions during the events.

In terms of events, our objective has always been to provide delegates with an exceptional experience. Whether through scheduled meetings and spontaneous encounters, Gartner summits provide an opportunity to show something about Smart421′s brand values which are an important part of who we are, what we do and why we do it.

Smart421 answering questions from Maersk Line

Smart421 answering questions from Maersk Line

I think that most delegates to industry events expect to be button-holed by the event sponsors; it goes with the territory. Yet, whereas this has been a bit uncomfortable at some other events we’ve done in the past, we’re finding that Gartner delegates are more ready to open substantive conversations. They are intelligent people who think strategically. They are more open to explain their challenges and are more prepared to listen for possible solutions.
This is refreshing and frankly a little unexpected.
Alongside the serious business of conference sessions and on-stand discussions, we really enjoyed laying on a bit of corporate hospitality for the evening Networking Reception. These receptions are deliberately informal and give a chance for each sponsor to select a theme which the Gartner events team reviews and approves. Each theme is designed to be as unique and as entertaining as possible for everyone to enjoy at the end of an intensive day of conference sessions. There were some great themes…
Jack Sparrow with Charlotte, a Smart421 Customer

Jack Sparrow with Charlotte, a Smart421 Customer

Smart421 selected a topical Pirates of The Caribbean theme (hot on the heels of the latest release) and invited the UK’s leading lookalikes to come along and help us. Simon Newton as Captain Jack Sparrow (Johnny Depp) and Sarah Key as Elizabeth Swann (Keira Knightley) delighted delegates by handing out champagne and chocolate, and many had their picture taken with them. We ran prize draws every 20 minutes and winners were drawn out by our MD Neil Miles, and by Keira and Johnny.

I think that the cinema chain Cineworld will be getting a lot of extra business over the next two weeks with all those lucky winners cashing in their cinema vouchers, maybe to watch Disney’s Pirates of the Caribbean: On Stranger Tides if they’re quick enough.

Jack Sparrow awards Cineworld tickets to Rita, one of our lucky prize draw winners

Jack Sparrow awards Cineworld tickets to Rita, one of our lucky prize draw winners

 Perhaps delegates visiting our stand didn’t find the Fountain of Youth but they certainly all enjoyed a glass of Taittinger champagne with us. 

No doubt Robin Meehan will blog about his findings from the conference sessions, so I’m off to re-count our hoard of pirate gold i.e. the belgian chocolate money we splashed everywhere to add some bling to our stand. 
Fans of the movies will know there are only 9 Pieces of Eight. At last count, we had 4,800.   Well, we didn’t want to run out – did we !

“Take all you can, give nothing back” crowed Jack Sparrow.

Smart421 stand and hospitality
Champagne & chocolate : enough to go round… several times.

All photos by Jim Templeton-Cross.

WUG 10th Birthday Celebrations, IBM Bedfont 23 March 2011

Members of the WUG Board, past and present, cut the birthday cake. From left to right: Nigel Gale (founding Chairman), Simon Maple (IBM Representa tive), Alan Chambers (WUG founder and Board member), Chris Mason (Treasurer throughout the WUG's 10 years), and Jonathan Marshall (IBM Representa tive). Photo by kind permission of Alan Chambers.

On 23 March, over 200 members of the WebSphere User Group UK (WUG) and members of the WebSphere Integration User Group UK  descended on IBM Bedfont Lakes, Feltham, UK for the WUG’s spring-time gathering (2 annual meetings; March at Bedfont, September at Edinburgh). Smart421 was there with one or two of our bigs guns. More on that in a moment.

As longstanding members of the WUG, we get a lot out of these meetings - perhaps ‘cos we also put  lot in. A significant number of our customer engagements require deep Java skills and several depend on WebSphere technologies in some way or another. Most speakers are IBM-ers, many out of Hursley, or sometimes further afield. Delegates from IBM, end-users of WebSphere and IBM business partners make up the remainder of the rich ‘ecosystem’ that is today’s WUG.

Smart421 Lead Consultant, Stu Smith, had his proposal selected by the Committee, which carried the catchy little title ‘Software Development Life-cycle with Message Broker in end-to-end SOA’ [Download the slides]. Nevertheless, Stu pulled a bigger crowd than usual with his piece and people seemed to appreciate his content and the very good Q&A session he triggered; for the last session of the day, it was a lively interactive exchange among attendees, who by then probably had their minds on the drinks reception or what they had to do to catch the early train home.

Alan Mangroo, one of our elite tekkies, attended for the educational tracks and was last seen diving in and out of sessions he has pre-selected. Knowing him, he’ll have made copious notes, so try to make a point of reading his separate blog [posted 08 April, click here].

The WUG has been running for ten years in the UK (yeah…I know !) and the Committee didn’t run past the opportunity to celebrate with drinks and two rather impressive cakes to mark the occasion. I’ve included a photo, courtesy of Alan Chambers, so you can share the moment with us. Proof –  if ever you needed it – that even tekkies have soul, so long as you bring the candles ;o)    Actually, I only remember cute miniature marzipan figures: developers with laptops.

As is often the case, Smart421 ran a on-stand prize draw for a bottle of Bollinger and appropriately Nigel Gale, the WUG’s first chairman (pictured, far left), was the one who swooped the 1st prize. Good timing I’d say. Hope you enjoy that, Nigel.

"Small opportunities are often the beginning of great enterprises" - Demosthenes

"Small opportunities are often the beginning of great enterprises" - Demosthenes

Did you know that of the 500 original companies of the original S&P 500 (Standard & Poors) in 1957, only 74 of those remained in 1997 – that is a staggering 85% reduction!

Why is this?

The capital markets in the world today encourages rapid and vast growth leading to greater revenues and wealth, meaning people are expecting companies to adapt and perform to the market conditions and are not too understanding when they under-perform over the long term. Of those companies that are no longer in the S&P 500 one of the key factors that they were unable to be keep up with the changing demands of the markets and been able to be agile in entering new high value markets. Whilst change can be slow, it is always powerful!

It is having this ability to adapt and change that helps companies today to survive and a great way to help your business achieve this agility is by adopting a SOA architecture. It can really help a business create an IT infrastructure that will support a truly dynamic enterprise.

SOA is all about defining services that align and support business process, and exposing these services so they can re-used easily. It also allows these services to change independently so only aspects of business processes that need to change (as the business adapts and changes) minimising the impact on the rest of the IT infrastructure and business.

The loose coupling gained from adopting a SOA also provides abstraction from underlying systems and applications. This allows greater flexibility on consuming and invoking the capability exposed through the SOA, whilst enabling the ability to  switch the underlying systems and platforms as and when this is required.

When you consider all of these benefits you can see the agility this provides your business.

SOA is nothing new and has been around for a number of years now (and in a number of different guises) but in our opinion it is now a widely accepted mainstream approach within IT architecture, which we are seeing with a number of our clients investing and driving forwards with SOA as they have realised (and are already reaping) the benefits that it brings and how that journey can be the beginning  of a great and dynamic future.

BizTalk Server 2009 was released end of April 2009. This tends to lead to  a natural  review of our internal handbooks and the utilities that complement our processes.

When approaching all BizTalk engagements we  initially consider the SOA Roadmap and development methodologies and test frameworks that support these approaches. The majority of the utilities/extensions mentioned here are available as open source, or free trial download, but rarely do I see these utilities combined. It is assumed that these are applied to the traditional base build of Windows, SQL Server, optional WSS and BizTalk.

WCF LOB Adapter SDK SP2 ( )

The LOB adapter pack has now been extended to support SQL Server and is worth considering when looking at using WCF bindings.

BizTalk Adapter Pack 2.0 ( ).

This is a 120 day evaluation extending the WCF LOB Adapter SDK, to enable the auto generation of schemas and ports for the additional new bindings. There is an additional cost for this pack, depending on the licence model of your client.

Nunit 2.5  ( ).

Still popular with clients and used  to manage BizUnit test cases. The more traditional option is mstest, but useful to include for completeness.

BizUnit 2.3  ( )  or 3.0 (

BizUnit is an excellent declarative test framework for managing test cases and for generation of automated regression test packs. The newer release 3.0.x.x has additional feature support. Some clients like to make use of the excellent BizUnit Designer, which provides a UI for test case generation over editing raw XML. This is useful for early adopters, helping with understanding of what features are initially available in the framework.

Microsoft BizTalk LoadGen 2007 (

An additional tool to coordinate the execution of performance and stress tests.

BizUnit Designer 1.4 ( used with BizUnit 2.3

 A useful tool providing a UI to assist with the initial creation of test cases.

BizTalk Deployment Framework  ( )

This is a must for any development team. Having used the older framework extensively, the new features support msbuild projects over nant. This is a real time saver when managing complex build and deploys.

HTMLHelp.exe ( )

A Pre-requisite for the HTML output of the following orchestration profiler/documentor

BizTalk Orchestration Profiler 1.1.1 ( )

An excellent tool for verification of code coverage of orchestrations in BizTalk. Generation of a help file analysing orchestration performance. Used during test cycles for verification of regression test packs coverage.

BizTalk Documentor v3.2 (  )

A useful tool for documenting the configuration of a BizTalk implementation. Useful to include in the deployment and release cycles for configuration management issues and to share with support teams, to verify configurations.

BizTalk Server Best Practices Analyzer v1.2 (

An essential tool for all client deployments to generate and understand compliance reports. The latest version supports BTS2006, 2006R2 and 2009.

MessageBoxViewer (

An invaluable tool for querying and analysing system configurations, especially for warnings of potential performance issues. This is more of a dynamic analysis than best practices analyser.

 Each of the downloads provides excellent detail on how to use the individual utilities. These are the utilities that we use to support our SOA Development Methodology when implementing and supporting BizTalk Server implementations. They provide the basis for development, test and deployment frameworks.

A few months ago I attended the Enterprise Architecture conference in London.  As we Enterprise Architects aren’t exactly a dime a dozen, I found it very stimulating to be able to participate in conversations with like-minded people.

Overall, I found the conference very positive as it reinforced my own belief that for Enterprise Architecture to add value to your organisation, it must be oriented towards the business community, and it can’t be just an IT-led initiative.

However, what became apparent as the conference progressed, was that two recurring themes were emerging: firstly, a lot of people do not understand what Enterprise Architecture is; and secondly, Enterprise Architecture is not Service Oriented Architecture (SOA). Unfortunately, some presenters seemed to miss the second point.

SOA is first and foremost an application and technology architecture pattern for defining reusable, technology-agnostic composite applications.  Used correctly, SOA will deliver value to your company’s IT estate.  But there are some essential facets of architecture that SOA does not address, the most important of which is the business architecture.

The common catchphrase of SOA is that it “aligns business and IT” – but how?  Everyone knows that this is facilitated by the services that you define, and these should be “business oriented”.  But there is more to business architecture than just service definitions.  For business architecture to be truly worthwhile it must encompass an holistic view of how your organisation is defined, what are its long-term goals and objectives, what its marketing and product strategy is, and how it interacts with its customers.  And how IT is used to deliver this.

This is why you need Enterprise Architecture.  Not only does it allow you to define your architecture within consistent, reusable models and artefacts that be shared across both the IT and business communities, but by separating these artefacts into separate architectural domains (e.g. business, information, application and technology), it allows your organisation to identify the inter-dependencies between these domains (for example, between your service catalogue and your information model), so that your architecture becomes truly sustainable and the benefits apparent to IT’s customers – the business community.

This is the message that was getting lost at the conference and within the industry in general, and unfortunately, some of the worst culprits are the SOA vendors.  SOA isn’t just something you can buy out of the box – architecture is something that your organisation must invest in, to define and build the resources that empower your enterprise.  As John Zachman so succinctly put it, beware of the enterprise silver bullet that some vendors will try to convince you is the answer to everything.

We’re fortunate at Smart421.  We use our Enterprise Architecture framework to deliver SOA (in fact, EA can be used to deliver any architecture).  Maybe you can find it useful too…

This point has been explained in many other places, but still seems to need reiterating for some audiences:

SOA means Service Oriented Architecture

The most important word in that phrase could be ‘Architecture’, not the ‘Services Oriented’ piece – that just applies a modifier for the type of architecture; it does not mean that SOA is just the use of Web Services. Those are a technical interface mechanism and related standards that are indeed prevalent in any SOA environment, but that is only a part of it.

I, and my colleagues, often come up against a technical-biased viewpoint that implementing SOA is just a matter of using Web Services, SOAP, XML and WSDL for application integration. Maybe this comes about from the frequent over-use of the ‘Technical Architect’ job title, but that would be a different discussion with no real ending in sight.

In this context, an architecture implies a framework that is used within an organisation, whether it applies to business, information, application software or technology infrastructure. An architecture should include some form of blueprint and an associated set of principles to be applied to projects or solutions that fit within that architectural domain.

For SOA, a blueprint is an absolute prerequisite for any implementations to go into that environment (actually, for design and even project feasibility). Along with the blueprint should be a set of standards and principles that can be used to ensure the strategic SOA vision can be met. Tactical solutions may deviate from the strategic aims, but only if they can be shown to have strong justification for breaking the defined rules, and even then should have further plans to bring the solution into line for future strategic use.

The process of defining and applying SOA standards is that of governance, which is a form of quality control that applies to a greater level than is commonly seen in technical development projects where design and code reviews tend to take a project-specific view.

For SOA implementations to be successful, services should be designed to support business needs, so that they can be reused by multiple processes and applications, and using common approaches for interface definitions, data models, error handling and security. If these are not defined up front, as part of the architecture, it is highly likely that each set of services introduced into the SOA platform will be inconsistent, requiring additional effort for integration into any composite applications or services. Some of these points, especially that of security, can be very hard to ‘retro-fit’ if a standard is defined after the implementation of a number of service-based solutions. The same problems arise for any other standards that may be defined ‘after the fact’.

Hopefully these comments give a flavour of how SOA requires a broader level of thinking for application and solution design. There is a huge difference between a set of ad-hoc Web Services exposed in an ESB product and that of an architected design using SOA principles for compatible, consistent and reliable service-based developments.

If you are embarking on an SOA implementation, you really do need to form this holistic view of applications, services and business processes, with an architecture governance programme to ensure that the defined principles are applied. Of course, this is where the full ‘Enterprise Architecture’ approach comes in to play, with SOA being a subset of EA.

To those organisations, or more likely, development teams, that are just extending their EJB or COM components with a SOAP interface on an ESB, you should refrain from calling this approach a Service Oriented Architecture, as it most probably is not. It is quite likely to be just another bunch of incoherent application interfaces that will form a birds nest (or can of worms) with connections crossing all manner of boundaries. Well, that is my opinion of what I have seen happen, at least. Oh, one other whinge on common errors, it is ‘Oriented’, not ‘Orientated’. Shoot me if I use the wrong phrase!

SOA isn’t trivial, but if applied properly it can be a much better way of developing solutions within and across and organisation. So don’t be put off by the apparent overhead – doing SOA ‘properly’ is a good idea and should ideally be undertaken as part of a new approach to IT solutions that are using best practices in all possible areas.

I hope you now agree, that SOA is not just about exposing and using Web Services, and that if you are one of those committing the ‘crime’ of misusing or abusing the SOA moniker, please think again and take a step up to the greater view of architected solutions.


Get every new post delivered to your Inbox.

Join 1,122 other followers