It's the same with the cloud. You have to define that in a very specific way and after you have that knowledge, then you can get into the specifics of what you need from the cloud to support your business.
Lawson: Did participants talk about the difficulties in even finding out what type of cloud solutions the business already has brought in? Is that just completely irrelevant here?
Spar: It's totally relevant and that's the current state technology. You look at the current state business operating model, you look at the current state technology, you analyze the gaps as to how well the technology is in alignment with the business and then you make a decision on the future state business operating model. And then, recognizing what the gaps are between two areas, one, the gap between the current state business operating model and the current state technology and, two, the gap between the current state business operating model and the future state business operating model, then you can say, "What do I need from my technology going forward?" And that's the discipline of EA.
The discipline of EA provides a structured way to do that and a structured way to then build your transition plan for business and technology to get there. I had several slides that very pointedly showed that graphically because that's the core of what EA is about: helping you get to that transition plan to the future by understanding both your business and your technology.
Spar: If you think back on the way that we want to describe the business and the technology, current state and future state, we talked about having products or artifacts that help us perform that. Several of the products people might recognize such as process models, others are a little bit less familiar to business people, such as data models.
What I've found over the time period of studying EA and what we found in consulting is that if you understand the underlying data, you'll understand the business with a greater degree of detail and a greater degree of stability.
Business processes are very viewpoint-dependent. For example, if someone is admitted to a hospital for treatment, the way that the patient would describe the process would be different from the way a nurse would describe the process versus a doctor or a hospital administrator. But yet the underlying data is the same in all of those processes.
Building data models, mapping and integrating them with different representations of processes and actors and systems is not only a unification and a discovery of where overlaps or redundancies can be improved, but it also gives you an opportunity to map it to systems in a more structured way and a lot of studies have shown that while business processes seem to evolve frequently over time, the underlying data almost never changes.
Lawson: How much of a consideration is integration when you're focusing on a data-driven approach to architecting anything, but particularly the cloud?
Spar: I think it's as important as ever. One of the philosophies we tried to espouse today is that it doesn't matter whether or not you're going to build the service or you're going to go to the cloud for the service. You need to define the data that you need, you need to identify what data is sensitive and you need to define a remediation plan if you have a security breach.
That responsibility doesn't go away even if you outsource to a cloud provider. A lot of organizations I believe have a little bit of an oversimplified view in that they think that a lot of those responsibilities are diminished once you go to another provider.
Lawson: Are there unique issues when you're looking at the cloud from an enterprise architect standpoint in terms of - I guess what are sort of the issues an EA should consider and are there unique issues for the cloud when it comes to security and integration?
Spar: One of the things we really need to make sure is that we build out proper security models so that we can take advantage of cloud and what it offers. I would say that many organizations need to work on their security models internally even before they consider going to cloud. As you consider moving in the cloud direction, what you need from security is even more critical because you may have less knowledge about where your data is physically located.
One of the things that I've found to be very helpful - and this is really branching out of EA and into security architecture - is the National Institute of Standards and Technology, the government agency known as NIST. They have a series of security publications, their 800 series, and they explain in detail what you need to have for security models for interconnecting systems.
What I've found is that in order to really follow that guidance properly, you need to understand the data of the organization, the actors and the processes that are using the data and then the systems that perform the functions that use those processes and data.
Enterprise architecture is all about breaking that out and understanding it through products or artifacts and once you have that done it makes it so much easier to follow the guidance of a publication like NIST 800-47, build security into your interconnecting systems. Those exact principles apply directly to cloud. With cloud coming on board, it formalizes in a sense and accelerates the need to have this defined.
Lawson: Ok, and with integration, anything unique there?
Spar: I wouldn't say unique as much as it creates the imperative that you do have to have things well defined, preferably well modeled in advance so that way you can take advantage of the cloud service, which would be off-site. And it's no different if you were to look at an offshoring model, you just have to have a more clear description because you're going to have a little bit less contact with what's being outsourced. Ultimately, the key to successful integration is to have those products or artifacts well understood.
I want to just say that EA is a very good way to approach a future direction of the firm. It's a good way to take technology strategy and turn it into something actionable with definable products and that the Open Group with the TOGAF enterprise architecture has put a lot of this online, quick reference and it's a resource most companies should really look into before they move forward in a big technology investment.