"We develop our frontends in Angular" is not an Architecture Principle

Did you ever hear that story about that architect who was telling the developers how to develop their solution? Badabing, badaboom!!!

Yeah, I know it’s a bad joke, there’s no laughter there. I better not aspire a job as a standup comedian. Thing is though that there’re still plenty architects out there that are not only defining architectures, but also tell the developers how to develop that architecture. It amazes me why this is the case.

I know that not that long ago I told you to ditch your architects when they are busy creating roadmaps. But actually you shouldn’t because there’s a real legitimate reason for defining roadmaps. The reason being that they’re an excellent tool. So ditch the architect when roadmaps are what they deliver, because those are the ones you want to get rid of.

Now there’s another breed of architects out there that I have a hard time to understand. I really think that architects should be architecting. That’s what their roles are, just like developers should develop. People should be doing what they’re supposed to do, and preferably spend some time outside their boxes while thinking about what their job really is.

For an architect, the sole raison d’etre is to have answers when asked questions and at the same time be enigmatic. Well, maybe that last part should translate into being helpful to whoever is asking the questions to get the answers themselves.

The architect, as I see it, is the one that defines the boundaries within which the developers can act freely while being confident that there’s no harm to the overall integrity of the enterprise or the organization for that matter. The strength of the architect, the real power, is that this can be done by defining Architecture Principles. These are extremely powerful because you can link them directly to your organisation’s mission, vision and strategy. Well if you can’t than you should reconsider your principles. But if you can, you’ve got your business justification for your principles and you won’t need to define the business value of those principles either. But just like any power-tool, they’re not trivial and to formulate the right principles you really need to be ready to spend some serious time. Furthermore, you need to limit the amount or principles to a maximum of 10, just like the 10 commandments. More will be hard to remember by heart and live by, which is what you should expect from your developers. Less is better, but beware of the fact that you should cover all the important bases in your environment.

There’s another tool that’s really powerful, which is the reference architecture. Which in fact is a model, one of the good kind as you can read here. A reference architecture is a model of an application that meets all the architecture principles. But beware; It’s a model, not an architecture! It’s a visualization of what the architect had in mind when he defined the set of architecture principles. And more importantly, it’s one of many possible models.

So as the architect defining the reference architecture you should be aware that everything in it, can, should and will be taken with a grain of salt. And as the developer you should understand that the reference architecture is just a tool for your architect to illustrate what was meant by the architecture principles, and definitely should not be taken literally.

Ah, so what about the joke, the bad one?

Well, there’s this group of architects that don’t understand the difference between architectures and models and instead of defining architecture principles and reference architectures, they tell the developers what and how to develop such that they comply with the principles.

There’re some serious problems here. For one, the architect omits the definition of architecture principles for whatever reason. Likely because it’s too hard, or they don’t see the benefit. Shame on them! Then there’s the case where the architect ignores the fact that the developers are very likely more proficient in developing than the architect. Oh, and let’s not forget about the fact that architecture principles are almost timeless, or at least stick around quite a bit longer than the typical technology, tool or framework. Yet, this architect dismisses this simple fact of IT and at the same time doesn’t keep the construction manual, because that’s what it is, in line with the current state of IT affairs.

For example, I discussed a couple of years ago, where ‘discussed’ is a euphemism for ‘verbal fighting’ with some fellow architects in some kind of architecture board that it made no sense to dictate that a multi-tier architecture should always be deployed such that each tier should be on separate infrastructure. Instead the application should be complying to the fact that data access logic not to be mixed with business logic nor with presentation software. Sometime ago I had a discussion, which was a real discussion, about whether or not we should define in reference architecture that either Eclipse or Visual Studio should be used for coding. Uhm, I think not, thank you very much. And yes, this was a real discussion.

There’s the discussion about what part of an application is developed in what programming language? We had the discussion at a startup I was Chief Architect at. Guess what, the developers made those decisions, I just stated the principles that I wanted them to comply with.

So what it actually boils down to is that architects need to govern, and that should take up most of their time. They should safeguard the integrity of an organisation’s IT landscape and make sure that in all cases the applications or rather the products in that landscape can comply with the architecture principles. The architect should promote and facilitate an unambiguous way of working among teams. The architect should also be concerned about an ubiquitous vocabulary within the organization when it comes to business and that it is translated by IT consistently.

The architect should not dictate that a particular programming language to be used, that a particular infrastructure is to be deployed to or that specific tooling is to be used. And in those cases where there’s a good reason for the architect to do this anyway, than it should be implied instead of explicitly dictated. In case all development is to be done in Java, the architect should ensure that only Java developers to be hired. In case everything should be hosted on Amazon AWS, the architect will have to pave the way for the teams to use Amazon AWS, making it the favorable option for the teams of the many hosting alternatives they can choose from.

As you might have guessed here, is that the architect I’m referring at is the enterprise architect or domain architect. Definitely not the application architect or the solution architect. The latter are both very much there to device a solution for a problem. They’re more like designers than architects in that sense. Which brings me to another little piece of personal amazement. Why are there so many large organisations that have domain architects on enterprise level whose domain has nothing to do with the business, but are strictly technical? Probably this is some remnant from the time that we considered IT to be a cost center and centralization of IT was the holy grail for many a CIO. Nowadays where we see IT as a product, something that is not just setting us apart from the competition but an actual product, there’s hardly any room for the these architects, at least not on an enterprise level. They should be working closely with products teams from the same product portfolio. Become Product Portfolio Architects, safeguarding the integrity of the IT landscape of the portfolio. Is it a demotion? Definitely not, it just means that they’re relevant again.

To paint a little context here, I’ve been that architect I’m complaining about. Emphasis on ‘been’. I enjoyed the technology too much to let it go, but as the domain architect I wasn’t allowed to work on the software, so all I had was telling the developers what to type. Initially I got away with it, because I was at least one of those architects that actually could still code. But really soon thereafter it became apparent that I hardly had enough knowledge or experience to really do the work. To me that was a real eye opener and I had to good fortune I was working with people that didn't hide the truth from me. They expertly conveyed to me that yes I was more than a decent architect, but as a programmer I really wasn't up to it anymore. And as much as that hurt at the time, it allowed me to focus on architecting. I still code, because I still think I need to be able to understand and to know that things might work. But as an architect, especially in an agile world I find myself more and more facilitating, communicating and coaching. Working 3 sprints ahead of the developers, not because I'm that a fast thinker, but because being an architect I need to be able to set directions. Let the team worry about how to get to our destination, be their own satnav system, and me the architect am more and more the person controlling the system's settings. Controlling whether or not to allow ferries, toll roads, to prefer back roads, go for the scenic route or the fastest or most economic route.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

Roadmaps are why you should ditch your architects

Summary

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Classification of Architecture Irritation

In case you're interested in finally getting that excuse to get rid of your architects, you're most likely frustrated with them, their architecture and probably you are not able to see any added value of the architect in your organisation. Therefore, I think you'll most likely fit into one of these groups:

• Your architect is too technical and strict, and that the architecture is too restrictive and technical.
• Your architect is just the right person for the job, and a great job he's doing with that just right architecture.
• Your architect is too high-level and vague to be helpful, and that the architecture is too high-level and vague to be useful

And in case you are an architect, you will fit in one of these three categories and your surroundings classify you as either too strict, awesome or just not helpful at all.

Now think about it really carefully... if you're the just right architect or you're dealing with that architect. Since how long do you feel that way? Has it been forever? Well, then this post isn't for you, but continue reading anyway. In case your answer is something like 'just recently' or 'since not so long', then this post is for you because there's a reason why it's been not since forever and it's bound to change in the near future. Well, it'll be very likely you'll going to move to one of the other groups.

The roadmaps are what make architects roadkill

When your architect already is one of those that you can't really consider useful, and is creating architectures that are not really helping you. Or when you're one of those architects. Well, you're in for a treat, because this is a cause of possibly the main frustration within your IT department. Or even within your whole organisation.

Now why is this?

This is because these architects only add time and costs to your projects and nothing else. They too often behave like auditors, telling you what's wrong and not how to fix it. But other than auditors, the architects refer to something they created themselves in the past, using the RTFM reply.
Auditors are a pain in the buns because they point you at how you're not playing by your own rules. Based on what your own definitions of good and bad are and what is and what's not acceptable, they'll verify to what extent you play by those rules. Architects, too often, will work on a reference architecture, architecture principles or even guidelines and that's it. You use their output to work on your own products. And you'll notice that as soon as you start using their stuff, it's either too restrictive (we develop software in either Java or .Net), too outdated (we develop our software based on JavaEE 5) or too vague (we develop our software based on the multi-tier architecture). Whatever it is, it's not helping and as soon as you ask your architect to do a scan of your products, it will be noticed that you're not using Java or .Net but NodeJS instead, that it's based on Java 8 or that it's an architecture based on SOA principles utilising a serverless infrastructure using Amazon Lamda.
So by either abiding the rules written or checking to what extent your compliant, you're loosing time and wasting money.

In many cases this is because people think architecture is a noun, while it is in fact a verb. Let me repeat that;

Architecture is a verb, and definitely not a noun!

So when you document an architecture, you're documenting a living thing. Something that is changing constantly.  So understand that when you come across a document with an architecture, look at the date of the document, because it's a snapshot of what the architecture looked like at that date. Or rather, it's likely to be the case.

But it doesn't end there, architecture isn't just some thing that changes constantly. It's an opinion of somebody who is mandated to be opinionated. What this means is that the architecture is also showing where you want to go as an organisation with your IT landscape. It's the as-is, the to-be and the route to get there. It's like a sat-nav system, it determines based on GPS coordinates where you are on the map, you enter your destination and it will calculate the route to follow to get at your destination based on your location. This is architecture. Well, part of it. The part that's relevant for this post.

That reference to driving and navigation is something I've done before. Read about it here. It's how I explain to my kids what my job is. I see where my client is, I negotiate with him where he would like to be and then come up with a plan how to get there. Including a clear definition of the impact on his situation along the way. Goods and the bads of the trip.
When you look at how many architects work, it's no surprise that they're so frustrating. The analogy with the SatNav is very clear in this;
There're those that will just hand you a (road)map and you just figure it out. See where you are, find where you need to be, plan your trip and go. And oh, btw, the date on the map is likely not very comforting. Or you'll get a turn-by-turn overview of how to get from A to B, based on the outset of when you started to plan your trip. It's based on some possibly old view of the world and any changes to the roads, terrain or otherwise are hopefully taken into consideration. But any traffic jams or other obstructions along the way are not in scope.
And then there's our trusty connected SatNav system. And the analogy holds. Because this thing is connected to the world. It not only keeps track of where you are during the trip itself, but it will keep an eye out to where you will be shortly. That won't be your final destination, but in case there's some roadwork up ahead, it will guide you past it. You'll be informed about relevant information along the way about gas stations and gas prices, hotels, restaurants etc.
The interesting part here is that those that have ever driven with a map, remember the fights between the driver and the person reading the map. Or those near death experiences when you were driving and reading the map yourself. And in case you printed that yahoo page with the turn-by-turn route to wherever you thought you were going to end up, you'll remember that all of a sudden there's a lot of places with the same name, roads are always under construction and the turn-by-turns are always irrelevant after the 5th turn or so.
These are the architects that think architecture is a noun.

The SatNav is constantly with you, and the better the system the more it anticipates on the road ahead, keeping you informed about your surroundings, distance to destination as well as the arrival time. It will keep in mind that weather conditions might be cause to divert your trip or maybe start the AC to make sure that the climate in the car matches the weather outside. This is when architecture is a verb.

Architects that are not with you along the way are of no use. You should not pay too much attention to them, they're not worth the frustration they cause as nothing good will come from it.
But if you find yourself in the company of an architect that is trying to be with you all the way, you should cherish that architect and consider yourself extremely lucky. Not only because your life will be better, but more importantly because this is a very rare breed.

Conclusion

I did already post about project managers and their demise here. Well, it's not a lot better when it comes to architects. Actually it's worse, because these architects, the ditch-able ones, are useless even in waterfall projects, but more so in agile projects, I give you that.
But where you can still find some use for most of the architects in waterfall projects, because as you know, these projects consider documentation as a key deliverable and are run under the premise that after creating the documentation for the next 12 to 24 months they don't need to change. In Agile projects this is different and this is why many scrum teams have said their goodby's to architects and even organisations have stated that architects are no longer need. And yes, this is the best thing that could have happened to our profession as IT architects. It's a matter of weeding out the turn-by-turn style and map style architects.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan

In principle, it's all architecture, unless it's not... or something like that.

Welcome to the wonderful world of architecture principles. A world where everything is a has to unless you've got a good justification not to.

This is an introductory for a multi-piece on a variety of Architecture Principles that I've come across in the last 5 years while working on Cloud, SOA and POA architectures.

Architecture principles are ground rules by which we develop our software. This ranges from ways of working to styles of coding, from software decomposition to business compliance, from infrastructure choices to security implementations. As you can see, it covers pretty much everything related to the development of business services, online, offline and internal.

Architecture principles are setup such that you just comply with them, unless there's a very good reason not to, and then you don't. A good example might be that everything is hosted in the public cloud, unless for compliance reasons we need to host on-premise.

All principles should lead back to our strategic goals, business goals preferably.

As a refresher, the way architecture within many companies works is as follows: As a company we have a mission, and a vision on how to accomplish the mission we've set out. There's a strategy on how to implement that vision, which consists of strategic goals that when met, we know we've implemented our vision. Turning the whole thing into a road-map from where we are to where we want to be with milestones to be reached, and steps to be taken in order to get to the next milestone. Our strategic architecture shows us the shape we're in at the various milestones, the tactical architecture shows us where we are after each step we have to take. Architecture is therefore a journey. It's not a noun but a verb instead.

Architecture is just like a satnav, you get your bearings and determine where you are, you set the location of where you want to go and the satnav calculates the best route depending on your settings regarding toll-roads, ferries and time our distance settings. And with every turn to be taken, the satnav recalculates the best route based on the most current information regarding traffic, road works, etc.

Architecture principles tell us the rules by which we live while on our journey, there's a justification for these rules explaining why obeying that rule takes us closer to our goal(s). Traffic law if you will. There's a speed limit on the road we're traveling. Obeying the law and sticking with the speed limit will ensure a save trip to our destination, but sometimes we have a passenger that's bleeding out, if we don't hurry and get to an ER, forgetting about the speed limit, caring for the passenger only. When we attest the traffic fine associated with the ticket for speeding the judge will waive the fine as a person's life is deemed invaluable. But if we just go speeding because it's so much more fun to go 200 km/h instead of the allowed 130 km/h there's no lenience from the judge as 'fun' is not considered a proper justification. Taking into account, and taking stock off the fact that every violation, even when justified, increases our architectural debt.

Architecture principles are therefore to be considered the default action to be taken, the default direction to head for. It's a matter of "This is how we do it, unless...". There are sometimes obvious 'unlesses', as in "We use Linux, unless Linux is not an option". But in that same vain, the principle could be: "We use Linux, unless Linux is not an option, then we use Windows". In which case there is no unless, there's no excuse to not use Linux or Windows. Every principle of this kind is clearly formulated as such. When there's no room to maneuver, there's just no room to maneuver.

Lastly, regarding architecture principles, we have to understand that principles will change, they will be revisited over time. As our mission, vision, strategy or goals change, our principles may have to change as well. As our world changes, our principles will change as well. They're not carved into stone, they're written using Permanent Markers. And we all now that permanent markers on a whiteboard can be erased with whiteboard markers.

Changing our principles or violating them, results in architectural debt. And as with financial debt, there is an interest to be paid. The more debt we have, the more our software costs. This is very much like technical debt that accumulates during software development, but where the interest paid on technical debt is typically analog to the interest on a mortgage or even a personal loan with a bank, architectural debt is close to the interest a loan-shark issues. And not paying of those debts, well the analogy continues there as well.

Without any further ado, let's start our journey...

Iwan

The Role of the Enterprise Architect

Hi,

Every once in a while I have to explain to people what the role of the Enterprise Architect is. And although this question isn't all that trivial at all, I still answer it with reasonable ease.

Disclaimer: I consider myself an Enterprise Architect, but with an IT perspective. This is important to note because it significantly limits my scope.

Another disclaimer, this post is from September 2011, since then, a lot has changed and although I've made some minor corrections in December 2014, you'll have to bear with me that the main gist of the post is 3 years old.

With that out of the way I can provide you with my answer to this question and explain it to you within the proper context.

Spoiler alert: The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

First of all I think that the Enterprise Architect's role differs from a Solution Architect's role in one very significant way; Where the Solution Architect is confronted with a problem and request to create a solution for it that complies with a given set of rules, laws, regulations, standards, guidelines and what not. The Enterprise Architect is confronted with the
current state of the world and an idea of how the world might turn out to be in the foreseeable future. And then is requested to define all problems to be expected to finally come up with solutions to all of them, such that they all comply with a set of rules, laws, regulations, standards, guidelines, etc. Some of which are unknown at the time the solution are defined.
Basically, the Solution Architect is given a problem and architects the solution, the Enterprise Architect has to come up with the problem first and then architect the solution.

With this out of the way, I can finally start answering the question: What is the role of the Enterprise Architect? His (or her for that matter) role is to create, govern and maintain the architecture of the enterprise from a technology perspective. Which more or less means that the Enterprise Architect is responsible for defining how the enterprise architecture as a whole is mapped onto technology. In the previous sentence I refer to the enterprise wide business architecture. And yes, I realize that this doesn't really has any meaning. Until, of course, I explain to you what I mean by enterprise wide business architecture. What I mean by this is the complete set of business decisions, visions, objectives, processes etc that have been formulated. It means the essence of the enterprise. The primary reason and motives of running the enterprise, its raison d'etre, if you would pardon my French.
The Enterprise Architect (from an IT point of view) is responsible for defining the IT perspective of this business architecture. He is responsible for defining which technology, principles, concepts, systems, applications etc are interrelated and how they are interrelated in order to enable the enterprise to meet its goals. And in addition he is responsible for maintaining this architecture, amending it as business goals evolve, and govern changes to it.

At this point I typically get the first blank stares from people. Rightfully so, because it is very abstract and Ivory Tower'ish. But there is a simpler answer which explains the role of the Enterprise Architect more clearly, in my opinion.

The Enterprise Architect is responsible for formulating the vision for the mid and long term from a technology point of view, the IT Vision. A vision that is in-line with the business vision. He is responsible for defining a strategy that is to be followed in order to realize this vision, the IT Strategy. A strategy that is in-line with the business strategy. And consequently the Enterprise Architect is responsible for creating a roadmap that when followed implements the strategy, the IT Roadmap. The IT Roadmap consists of strategic business projects that implement key milestones and are fully in-line with the IT Strategy as well as strategic IT projects that facilitate in the implementation of the IT Strategy.

Although the Enterprise Architect has to be constantly aware of the ever changing environment and adopt his architecture to remain in-line with the business architecture. This in part as a result of a changing business vision and consequently changing IT Vision. The Enterprise Architect will also have to reconsider his IT Strategy as well as his IT Roadmap based on a changing market. Typically in organizations this is a yearly recurring effort.
This caters for the creating and maintaining the IT Vision, IT Strategy and IT Roadmap in order to create and maintain the Enterprise Architecture. It does not cover the governance of the Enterprise Architecture. In order to implement governance, the Enterprise Architect is also responsible for defining and enforcing all policies and procedures that required for ensuring that project executed within the enterprise (both IT and business projects) are according to the set strategy.

For example, when the IT Vision is that the vast majority if not all (business) services are running in The Cloud [scroll down for a footnote on this 'vision'], and the IT Strategy is to implement in order a highly virtualized infrastructure which is then complemented with cloud administration services such that a private cloud is the result and finally all systems are moved to a public cloud as a means of out-sourcing the infrastructure.
The roadmap might be to initially select and implement virtualization technology, then migrate core systems to platforms that are supported in a virtualized environment, then select a cloud provider that supports the selected virtualization technology, then implement iteratively cloud administration tooling.
The Enterprise Architect is then responsible for ensuring that a set of policies, standards and guidelines are defined, implemented and enforced, that enforces applications to be cloud-ready. This may mean that certain paradigms are followed, for example that new infrastructure software and applications running on them are horizontally scalable in order to increase capacity such that performance requirements can be met.

It is utterly impossible to enforce compliance to IT Strategy for all systems, applications, projects etc. The Enterprise Architect, in collaboration with the business, will have to classify each project, system, application as being strategic, tactical or opportunistic.
Strategic projects (implementing core systems) will have to be completely compliant with the IT Strategy. These projects are implementing systems and applications that are planned to last for a long time within the enterprise and perform core functionality to the business. Typically they are planned to outlive the IT Vision or even the business vision.
Tactical projects can deviate from the IT Strategy but are required to be in-line with the IT Strategy. You could say they have to be in the spirit of the IT Strategy. These projects are typically implementing core business functions but for any reason cannot be implemented completely in-line with the IT Strategy. For example because the vendor does not yet support the selected virtualization technology for all components of the application.
Opportunistic projects are those projects that have a strong business driver to be implemented within a short time frame. Possibly because the particular bandwagon needs to be jumped on.

The interesting thing about an enterprise architecture is that treats those components that implement it on a physical level (hardware and software) as black boxes. At least to a certain level. The Enterprise Architect is concerned with the concepts of the various components but not so much with their implementation. By this I mean that the Enterprise Architect defines for example that all applications will have to run on a common application server infrastructure. This is the concept of farming, the infrastructure consists of a set of farms that host applications and applications components (application server farms, messaging farms, database farms). The idea behind this might be that infrastructural software is to be considered a commodity. How these farms are actually implemented (clusters of active nodes, clusters of active/passive nodes, etc) is not so much the concern of the Enterprise Architect but more for the infrastructure architects (middleware, database, etc), who in turn will be required to implement these farms compliant to the Enterprise Architecture. Even more interesting is that the Enterprise Architect is responsible for documenting the complete enterprise architecture as he own the enterprise architecture.

Although I realize that I haven't mentioned anything about the information architecture in this post, this is where I want to leave it to. Me for myself am not entirely sure whether the information architecture is part of the Enterprise IT Architect's responsibility. The thing with the Information Architecture is that it, in theory, is a business affair. The information architecture should be owned by the business. But practically I've seen it considered an IT affair in most pretty much every organization I've been. This is mainly due to the fact that the data architecture and information architecture are considered one and the same, which is in my opinion, because in most organizations it is considered to be impossible to create one enterprise wide information architecture. As a result, data architectures are not derived from a global or even local information architecture but from the physical needs of applications. But this is something worth its own post which I will work on some other time.

So this is what I consider the role of the Enterprise Architect as a role within an organization. But, there's more... Since the Enterprise Architect is one of the most senior roles within an IT department, if not the most senior role, I also think that as an employee within the enterprise the Enterprise Architect has also the responsibilities that come with this level seniority. In many cases the Enterprise Architect will have to act out of his seniority instead of his role. And this responsibility differs significantly from one enterprise to another.

Thanks for reading all the way to the end. It's become a long text, but I hope I've been able to explain my view on my role as an Enterprise Architect. Probably there's a lot you disagree with and I would love to hear about it.

Iwan

Footnote on the vision of having everything in "The Cloud"; Of course, it is not clear as to what the cloud actually is, even when you take the definition provided bij NIST. But the problem here is that everything in the Cloud is considered an IT Vision, which is of course not correct... but not uncommon, unless the  Cloud is considered placeholder terminology where the IT Vision is actually to no longer own physical infrastructure, not even from an outsourcing perspective.