Interview with Jason Bloomberg
Our very own Paul Preiss sits down for an in-depth interview with Jason Bloomberg, CEO of Intellyx.
Paul Preiss: Today we have Jason Bloomberg from Intellyx. He's the CEO, a very prolific writer, and a very prolific thought leader. I'm so grateful to have you on today. I'm curious if you could update our readers a little bit about you and what you've been working on, and things that you're thinking about these days.
Jason: Since this audience primarily is made up of architects, many of you would be familiar with me from my twelve years at ZapThink. ZapThink was an industry analysis, advisory, and training firm focusing on service-oriented architecture, and I ran the Licensed ZapThink Architect course for a number of years around the world. I certified about 17,000 architects around the world while I was doing that.
My new company is Intellyx. Intellyx is also an industry analyst forum, but we're focusing on digital transformation and the business agility that organizations need in order to achieve their digital transformation goals. Back in the SOA days, we talked about business agility as one of the primary goals of SOA, but in many cases SOA didn't live up to that promise. People got bogged down in the technology side of the story. So essentially what we're doing is saying, "Let's take the next step and focus on business agility." And then, let’s think about how we can better architect our technology to meet business agility goals.
Paul Preiss: Well that's a very important topic. I see a lot of opportunity in the industry for organizations to try to understand agility, to try to adopt these practices in more than just a development context, but as a business. With regard to agility, what do you see as the bigger trends today for architects?
Jason: A very important question is really, "What does business agility mean, and how do organizations actually achieve it?" And unfortunately, that word "agility," because it is based on the word "agile," ends up confusing a lot of people because they think when we use the word "agile" we mean Agile methodologies, or what you might call "Agile," with a capital "A." Following the Agile manifesto is a part of the story, and when we extend that to enterprise architecture and the furtherance of business agility, we're following some of the Agile principles out of the manifesto or extending them in a loose way to the broader organization.
But, there's still a lot of confusion over what does "agility" really mean, and when we say "agile architecture," there's even more confusion because some people will be talking about Agile Software architecture, the software architecture that is appropriate for Agile development projects. When I use the phrase, I'm talking about agile enterprise architecture, or better or newer different approaches to E.A. that drive this agility in the organization.
Understanding that second definition, how can we essentially revamp the process of E.A. so it's less focused on paperwork? It's less stuck in the documentation and framework-centric days - rework it to focus more on this business agility driver. What does that mean for the practice of E.A. and the role of the enterprise architect? That's a very exciting growth area for architects around the world.
Paul Preiss: What does it mean for an organization to be agile?
Jason: Well, when I define business agility, I break it down into three elements: One is resilience, being able to bounce back from adverse events. The second is responsiveness, which is responding quickly and efficiently to forces, market impacts, or changes in the environment. The third is innovativeness, being able to introduce your own changes, your own disruption into your environment on purpose in order to receive a strategic advantage.
Resilience and responsiveness are on the tactical side, you're achieving short term benefits, or mitigating short term risks. Innovativeness is really the big win, because that has a strategic benefit. If you're able to innovate, you're able to gain market share or achieve other strategic goals of the organization.
Business agility covers all three, and is essentially a property of the organization as a whole. That is, it's not pieces of technology that exhibit business agility, but it's the organization that exhibits business agility. That's the challenge of the architect: What do we do with the individual elements, with the people, and technology, the organizational units, the processes, and the information that we're dealing with. What do we do there to achieve greater business agility for the organization as a whole? The way I see it, that's really the best way to think about the goal of enterprise architecture.
Paul Preiss: Let's talk about resilience and responsiveness. How can a team of architects dealing with your average enterprise take action specifically to get the ability to adapt more quickly? What are the characteristics of the organizations that you see are good at this?
Jason: Responsiveness, in many ways, is the easiest or most straight forward of the three and every organization is responsive to their environment in a certain way, to a certain extent. So, being able to deal quickly and efficiently with change becomes the differentiating factor. Instead of doing it in a slow way, do it more quickly. We see a lot of responsiveness driving agile development efforts.
If you could take a long waterfall project that tends to fail anyway and scale that down. Scale an 18 month project down to a matter of a few months where there's a much higher chance of success and it's iterative and more customer focused, then you're going to be more responsive to customer needs, more responsive to the requirements of your organization.
With regard to responsiveness, a lot of organizations have a handle on this because its really at the heart of the Agile approach to software. Of course it's more than just a software story, though, right? The rest of the organization needs to be responsive as well, to learn organizational and process characteristics as well. There's a lot of detail there. The enterprise market has to think about software, as well as information, and process, and organization. The whole organization has to be responsive.
Resilience, is a different story because it's responding to adverse events. Essentially, resilience is a risk mitigation exercise. You're responding to performance issues in terms of your technology, things crashing, or websites going down or going to slowly. It's sort of traditional technology resilience, but also the resilience of the organization in the face of adverse events. Whether they are unexpected, competitive pressures, your competition lowers their prices and now you need to respond. Or maybe there's a new competitor, or maybe there's a change in regulations or a new geo-political situation where there's a trustier organization. Now the organization has to be resilient as well as the technology. In terms of resilience engineering, how can we build big digital properties, websites with mobile elements, so that they don't go down, they fail gracefully and we're able to figure out what the problem is and bring them back up quickly? That's all technical resilience.
On the organizational side, often the challenge is essentially having the right frame of reference for what it means to achieve strategic business goals. Let’s say an organization stays focused on simply driving cost out of their operations. You know - better, faster, cheaper - where you're looking to reduce costs and optimize everything you're doing and you're focusing on short term business outcomes, which is a very common way of managing an organization. Essentially, you'll end up with a more brittle organization.
Then, the unexpected happens, and now you're not prepared for it as an organization and that can lead to failure scenarios where you're unable to deal with some sort of unexpected event organizationally. These two notions of technological resilience and organizational resilience go hand in hand especially when we start talking about business transformation.
Organizations who are struggling with this whole digital picture, what that really means is that they are regaining or achieving a greater focus on their customer even though the customer wants to use a variety of different technology touch points to interact with the business. So instead of saying, "I'm just going to use the web for this. I'm going to use the call center for that, or use our sales floor for this." Well now the customer is saying, "I don't want just one channel, I want to be able to interact with the business any way I feel like."
As a result, they’re raising the bar on what it means to support the customer. You need that technology resilience because customers expect websites and mobile apps to be up and running and behaving very quickly. But, it's also organizational resilience because anything unexpected should be something that the organization can deal with as well. Then that ends up connecting to innovativeness as well, and I know you wanted to talk about that too.
Paul Preiss: You work with organizations on becoming more resilient and responsive. What do you notice as the changes in their thinking cycles, specifically do you notice that organizations budget on smaller increments, or budget differently, or don't budget? What are the characteristics, and I guess components of an organization that is business resilient and business responsive?
Jason: Just looking at resilience, it’s essentially an aspect of risk mitigation. It's in the same category as investing in security, for example, or regulatory compliance. These are risk mitigation activities. Any executive would just as soon not spend any money on that stuff. It would be great if we didn't have to spend any money on security, but unfortunately we do. It's a necessary evil.
So, when we look at our threat profile, the challenge now is to make sure one, we're looking at the whole picture. We don't just look at a piece of the risk story. You figure well, "Our website might have a vulnerability, so we need to protect that." If we only protect one thing and leave other things open, well then the bad guys just know the other things. So we have to make sure we're covering the whole picture, organizational risks as well as technology risk.
Then, second, we have to make sure we are talking about actual risk as opposed to the perception of risk. Perception of risk often drives organizational decision making more than the reality. We see this all the time, for example today there's all this concern about Ebola. Well, Ebola is extraordinarily low risk, the chance of an American citizen catching Ebola is like 1 in 1,000,000,000 or something. There's a much greater chance that you'll be hit by lightning, bitten by a shark and the Cowboys will win the Super Bowl, than for any particular individual getting Ebola.
There's a perception because of the news media and the way that mass psychology works that Ebola is a much higher risk than it actually is. Perception is important because it drives marketing, it drives customer behavior, but when you're talking about risk mitigation, you need to understand the actual risks. So you need to protect against the more severe risks, and invest appropriately.
There's an old saying in the risk mitigation world, "Perfect security is impossible." Another way of saying it is, "Perfect security is infinitely expensive." And you don't have an infinite budget for security so you cannot drive your risk to zero. So, for any organization, there has to be a particular balance, a risk profile. This is how much risk we're willing to tolerate, and this is how much we're willing to spend to mitigate those risks, and those two have to be in balance.
The classic example are the credit card companies that realize there's going to be a certain amount of credit card fraud. They could spend more money to reduce the fraud and they do reduce fraud to a certain extent. But, how much they decide to spend on fraud mitigation balances with how much fraud actually takes place, and what their losses are. And, because they're working with large numbers, they are able to achieve a very rational balance between those things.
It's much more difficult if the risks you're dealing with are organizational risks. For example, what is the risk of not taking advantage of the next competitive move by another company or not jumping into the market at the right time? There's all sorts of risks, so it's important to balance all of those. If you work with the performance engineers, you will find that they are worrying about how fast the website goes, or what could take down the website, and they’re making sure that they can find problems on the website. That's great. You need to spend money on that, but you don't want to spend more on that than is justified on the basis of your budget for mitigating these other risks. They could be security risks, compliance risks, or these marketplace risks that are often the ones that catch companies unaware. This is especially true if they are not up to speed on the changes in the marketplaces and changes that customers are driving.
That circles back to the digital story. Digital transformation is driven by changing customer behaviors. In particular, consumer behaviors. But, even for business to business organizations, their customers or businesses have consumers that are driving change throughout the entire economy at that point. Those become the most important types of risks to be aware of and to balance against the more technical risks that are in some ways easier to measure.
Paul Preiss: This is actually the key word that you used there that I wanted to talk about was, "measure." One of the biggest challenges, and it's certainly something we teach in our course, is the relationship between business measures and the appropriate business measures, and an organizations ability to think effectively. We see architects struggle with this because a number of those measures are, effectively, made up. They're not make believe, but they're approximations of reality. How do you see that playing into this concept of agility?
Jason: That's an important question, and this is an area that definitely needs more work and I'll be writing about this more in the future. This is actually where the big data story fits into this picture. One of the key benefits of big data in organizations today is it can help you achieve these more fact-based measures of business performance overall.
One of the main challenges with big data is the fact that we can collect so many more diverse types of information. It's a larger quantity but also a larger variety of information. The 3V story. The variety, as well as the quantity of information.
An organization utilizing that information properly will be collecting large quantities of information on how well they are doing. Then, that should feed back into improvements on an ongoing cycle. Iterative Business Improvements has been with us for years. It's a principle of the Deming Management and it was part of Total Quality Management in the 80's. So we've been doing the iterative business improvement as a traditional management practice.
What we didn't have in the Deming days, and the TQM days was the big data storage. Be able to collect vastly larger quantities of information and to process them even though we don't necessarily know when we collect that information what it's going to be good for. We don't necessarily know when we collect customer statistics, or other information that we collect, that the underlying cause of some observed effects might be how we set salaries or how we hire people. Or it could be on the technology side, such as how we go about mitigating performance risks on our website. We don't know yet because we have to do the analysis.
One of the challenges here is essentially putting things in the right order. A common fallacy that people fall into is confirmation bias. Confirmation bias is essentially starting with a hypothesis and then only looking for information that justifies the hypothesis. You think of an idea and then you look for evidence that proves you right and you discard evidence that proves you wrong. Low and behold, it looks like you're right, but this really has nothing to do with if you're right or not.
If we instead start with the data, and go where the data tell us to go. Then we're more likely to make the accurate conclusions from that information. That's part of the practice of predictive analytics. It's giving us fact-based ways of making the predictions, instead of the "seat of the pants" ways that are part of every management fad since Winslow Taylor invented the practice of scientific management back in the 19th century.
We finally have this chance to take things to the next level and say, "Well, we really need to have data driven, fact-based ways of making decisions about how to improve our business." With that being said, you don't want to get caught in a "faster, better, cheaper" trap. All we're using that information for is to optimize our business. If all we're focusing on is optimization, we are not going to be able to innovate. So optimization and innovation, at some level, are at odds with each other and that is also one of the challenges we have to address.
Paul Preiss: In the materials that we teach in baseline business skill development for architects, we talk about the different types of value that can be created. This is very much a value-based approach. As we get into more and more information about our business, one of things we're seeing is organizations needing to analyze that information better even to come up with operational measures of value. More customers is good. Well, more customers is good as long as your margins are appropriate, a number of other things, and you can handle the delivery of those orders and all of the other components that go into having a successful customer relationship and a successful sale. But, we find that IT, specifically, has issues in this notion of what to measure, and how to measure it and then take that information and turn it into value based investment decisions.
One of the tools that's emerged over the past few years is the architect governance board. Not the "what we're going to build technologically," but the "what are we going to make our enterprise look like in the next cycle of innovation?" I'm wondering how you see that in relation to agility.
Jason: Well, when I talk about governance, the challenge that I see is the traditional approach is essentially part of that old waterfall way of thinking, where governance becomes a set of manual activities that are paperwork-based and slow the organization down and lead people to try and find ways around those governance practices and policies. The whole problem with traditional governance is part of the reason why we have shadow IT and the whole, "bring your own device" problem. People want to be able to do far more with technology than these old fashioned governance boards are letting them do and as a result they're just making end runs around them. Sometimes people say, "Oh that's fine. You just go ahead and do it." But if you have some sort of security or compliance breach then everybody is going to be pointing their fingers back at the governance board saying, "Why didn't you provide adequate governance so that we would have these security and compliance breaches?"
I think the secret is to solve not only the problem with governance in and of itself, but also moving forward with the whole shadow IT phenomenon is to essentially evolve the way we handle governance. We need to essentially move toward a more automated model, where we're able to represent policies in meta data representations and then leverage increasingly more sophisticated governance technologies to automate as much as we can. Now, there's always going to be a role for human governance because it's not just about what we can automate, but we can do a lot better than we're doing now.
This was a part of the SOA governance story all along that we talked about and got started on, but we only really made baby steps in the SOA governance days. We were talking about SOA governance in terms of standardizing representations of policy. We had standards like WS policy, which had enormous promise. Here's a way of expressing policies as XML based meta data, and a way of doing Boolean math with them so we can combine them and we can now teach our technology to enforce them in an automated way.
It turned out we could do that in a very limited way, so enterprise service bus (ESB)-based policies we were able to do some automation and some security policies. We really didn't have a handle on how to do that more broadly, but we're increasingly learn how to do that. I think that's going to be a key part of the story: moving to a more automated and fundamentally more agile approach to dealing with governance, where we're treating governance as a challenge, the same way we would treat a waterfall based development as a challenge. Let's rethink it. Let's be more customer focused. Let's learn our tools better. That being said, there's still details missing. I haven't necessarily answered your question as much as I might possibly. But, at least that gives you a direction that we can head.
Paul Preiss: Governance is critical to success with Agile. We know that. We also know that the Agile movement, at least the development focused movement, speaks to a high-quality people based approach. Instead of big processes and big documents controlling everything, let high-quality people get in the room and do what they do. Call it self-directed complex systems. Or, deal with complex system governance in a self-directed, self-organizing fashion. We see this as a part of just being the Agile process. What has to happen in Agile projects even, again going into the IT world, for them to be truly architectural and to avoid high governance exemption rates, is that Agile requires more architects as people and hire quality architects. Then the original kind of thinking was, "Let's do Agile and get away from these architectures."
But if you take architecture as a people-based innovation process, as opposed to a document focused, capture or modelling design process, it turns into a very powerful addition to the Agile delivery method. Would you agree with that? Would you change that? What kind of advice would you give to Agile teams that are looking to bring better architecture into their practice, and how they can get out of this "architecture as big design" and "architecture as big governance," and so forth?
Jason: Those are actually two great questions that connect together, but let me address the first one and then move into the second. The first point you were making was how we're shifting governance from being paperwork-driven to essentially people-driven with self-organizing teams. Self-organization is a critical part of achieving the right emergent properties we want from the complex system that is our organization. This has been a core part of my research since the early days at ZapThink, recognizing that the enterprise itself is a complex system, a system of systems where the component systems were both people and technology. So the challenge then is achieving the emergent properties we want in business agility as essentially an emergent property of the organization. When I said earlier that business agility is a property of the organization, I was indicating that it is an emergent property of a complex system.
Part of the challenge if we're looking to architect a complex system, though, is that we can't use traditional ways of thinking. We can't say "Okay we want to build a bridge." So, go draw a bridge and make sure it doesn't fall down, and that's how we architect and engineer a bridge. A bridge is not a complex system. We don't want emergent properties. They're usually bad things when you're building bridges.
But, with an organization, essentially, what we do is we twiddle the components and see what emergent behaviors result. They may or may not be predictable and if they're not what we're looking for we go back and twiddle some more. It is an inherently iterative feedback based approach and so my comments about having fact-based, data-driven feedback loops is a critical part of how we go about architecting organization. Over time we continue to improve even though the environment is always in flux. And that environment being in flux is essentially why we need to be agile. We need to be able to deal well with change, so change has to be a core part of how we architect everything that we're doing, the full spectrum of enterprise architecture.
So the key part of that story is the notion of a self-organizing team which at that level is ungoverned, or you might say self-governed. There's no formal governance. That notion of no formal governance, where you have some sort of team and they go off and do whatever the hell they want, well that strikes fear into the heart of CIOs. They're thinking, "Wait a minute. I can't have teams do whatever they want. We have a business to run! We have business priorities. We have security roles. We have regulations." And so obviously we can't do that, but that's the wrong conclusion. The right conclusion is to say, "Well, certain things that we do will benefit from self-organization. We want to essentially allow these teams to leverage disruption and to introduce disruption into their behavior because that's how we achieve greater innovation while within the context of the overall global constraint."
Within the context of the regulations we all have to follow, and the security rules and the other constraints, we have to have a way of maintaining those at the boundaries. The self-organizing team can do whatever the hell they want within the context of the overall boundaries that define the enterprise. They're not just a start up or just making it up as they go. They're within a large organization, and as a result they still have to maintain certain large organizational enterprise characteristics. But, we want to do that as little as we can possibly do, because we don't want to defeat the whole purpose of having a self-organizing team. So we want to empower them to truly self-organize, so management doesn't tell them what they're supposed to do, or how they're supposed to do it, or how they're supposed to assemble their team, or who they should have, or where they should work, or how they should dress, or anything. All that the external constraints should be are guidelines. Here are our security roles. Here are our compliance rules, or for example, here's how we handle disaster recovery. Here's how we handle high performance, and so on.
At Netflix, they introduced the Chaos Monkey. We're going to have processes that are going to go out and kill things in production all the time and anything you put in production has to be able to withstand that. That was the rule. The developers are left to do whatever they want and they made up their own products and they built their own teams, but Chaos Monkey is there. So if you put something in production and the Chaos Monkey takes it down, you didn't do it right.
So that's sort of the notion. We're able to put these rules at the boundaries and as long as you maintain those rules at the boundaries, then you can maintain the enterprise priorities. Those include core business drivers, it could be profitability metrics, etc. But, now the software organization is able to innovate.
The whole organization doesn't have to be that innovative. Different parts of the organization do different things. Groups that are meant to be innovative can innovate. This can be digital teams that have software developers as well as product people. It's sort of dev off extended across to the business, cutting across business and technology. These are the self-organizing, innovation teams that are essentially driving digital transformation efforts. So that's a key part of the story.
The role of the architect on an Agile development team? On one hand, is an Agile principle that you never want to overbuild. You never want to do more design than you have to, you want to be as parsimonious as possible with your design, so you're only designing what the business needs in that particular sprint. You're focusing on business need on a short term basis that way. And, that's fine except if the business is saying, "Build me something ... No, make me more agile. Build me something that is inherently flexible so that I don't have to keep coming back and asking you to build something new every single time something changes."
This is sort of the paradox of Agile. The whole Agile development frame of reference is focused on building software. Which sort of makes sense because it's all about software development, so naturally, they focus on building software. How do you achieve greater levels of agility by building software? You build it better, and you build it more quickly. That's what Agile methodologies are focused on. They're not focusing on making it inherently flexible. The challenge with building inherent flexibility into software is it takes architecture. That is, you have to design capabilities into the software that are not only part of the short term requirements.
If you don't do this right, you're overbuilding. You're essentially saying, "I'm going to build all of my software so it's imminently reusable without any rhyme or reason." And you'll end up with all this extra code you don't need and it's not going to give you any real flexibility. It's just extra code you don't need and that's what all. Everybody wants to avoid that.
The challenge here is essentially one of balancing inherent flexibility with technical debt. Here's another concept that is critically important to the role of the Agile architect. How do you deal with technical debt? So this is another discussion.
There are two different kinds of technical debt, what I like to call good technical debt and bad technical debt. Most of the time when people think of technical debt, they're thinking of the bad kind where essentially, you're in a rush so you introduce sloppy code that becomes somebody else's problem in the future. The longer you wait, the worse it is because it's somebody else and there's no documentation of course. There's all these other codes layered on top of it, so now all the sloppiness makes the whole thing sort of precarious and that's bad technical debt. You don't want to write intentionally sloppy code simply because you're under time pressure. That doesn't end up with anything good when you do that.
The challenge here is good technical debt. So good technical debt is actually part of a well-run Agile project. Good technical debt is essential simplification or missing functionality in order to achieve the short term goals of the current sprint or whatever you call your iteration. This is something that Agile developers do all the time. They say, "This project has so many sprints, and so then end it will have to be done. But this first sprint is not going to get everything done, it's going to get certain things done." Part of our self-organization, when we need to sort of hash it out, will be figuring out what goes in what sprint. By leaving stuff for future sprints, you're introducing technical debt. You're introducing something that you'll have to fix later, and that's what technical debt is. If you do it right, then it essentially facilitates the Agile initiative.
Coming back to the notion of building inherently flexible software, essentially that is a form of technical debt. You're building something today where you’re basically saying, "I have some sort of requirement in the future and I'm just going to sketch it in today. I'm not going to complete it today." That now essentially becomes an architectural challenge, where the role of the architect now has to help coordinate what inherent flexibility you want, and when do you want it and how do you build it in a way that maintains the overall goals of the organization.
Connecting the software goals to the rest of the goals. To the governance goals, to the information-centric goals, to the organizational goals, to the process-centric goals. This is why it's so important for the architect to have an enterprise architecture context. You have to think about in the context of what the organization is trying to accomplish. That now becomes the role of the Agile software architect.
If you assign the role of architect to one person on an Agile team, you're susceptible in a way to the Ivory Tower problem where that person goes off and does their own design and is not in proper communication with the rest of the team and that leads to all sorts of issues. For any Agile architect from one of our Agile teams, it makes sense to break up that Agile architect role and make different people do it, so that their all sort of participating. This is a lean principle, everybody can do anything and they're all contributing to the success of the overall initiative.
That can work for certain teams, but keep in mind are somewhat specialized. Not every developer can be a good architect. So you don't necessarily want everybody on a team to have an equal say in the architecture because some people just won't be as good at it as others. Now this is part of the self-organization. It's up to the team to decide how they want to do it. Should one person be the architect either because you think that they can communicate well, and work well with the team? Or, do you want to divide it up into certain other people because they'd be good at it and you want more than one person to do it. That should be left up to the team to decide.
Paul Preiss: What are your views on innovation as a science, as a practice at organizations? What do you see happening in organizations today, and how are architects best set up to get involved with this. How can they set themselves up, I should say, to get involved with the innovation trends and life cycles at the organizations?
Jason: The first thing to remember about innovation is that it requires disruption. Disruption can be external, so some unexpected external force is causing the organization to innovate. But more often than not, it's internal. It's intentional disruption where the organization says, "We have to shake something up. We can't just do whatever it is the way we always have. We have to make something new and different and innovative. So we're going to disrupt the way we currently do business in some way."
This can be difficult for organizations because disruption always introduces risk. Essentially, you're throwing a wrench in the works to screw things up and as a result unpredictable behaviors will occur, and those can lead to risk. So this is part of why it makes sense for the executive, the CIO who is in charge, or the chief digital officer who's in charge in both keeping the systems up and running as well as driving innovation. Then it'll often make sense to say, "Okay, these are the people that I'm going to say you go ahead and innovate because you're going to be introducing disruption. You get to do that however you want." Or, here's some disruption. There's a wrench in the works and you have to deal with that and just let them innovate while the rest of the organization is still maintaining keeping the lights on, keeping systems running, and maintaining your security compliance and other governance boundaries that the whole organization has to comply with.
The disruption then essentially drives innovation. This is actually a complex systems principle similar to what we see in the process of evolution of species. If you look at the evolutionary record, sometimes a species will be stable for many millennia. They won't evolve very much. Then some sort of disruption occurs, you know the proverbial asteroid lands, but it could be anything, it could be a flood, or an ice age, or whatever it is. And that kind of disruption causes periods of accelerated evolution. These are essentially a set of emergent properties that the disruption leads to.
You need to be able now disrupt the organization in ways that lead to this innovative behavior. People will inherently adapt to the disruption and that leads to rapid periods of emergence where you have new unexpected behaviors and properties and that's essentially how creative people drive innovation. Disruption plus creativity essentially leads to this innovative state.
From the perspective of management, then, it's providing the right groundwork to make this work. Figure out who the team is, who all the people are. They'll break up into teams as they see fit. Then, give them the tools that they need to be successful, provide these overall boundaries, and give the team your overall goals, and constrain where constraint is absolutely necessary, and then leave them alone otherwise. You let them do what they do, in order to achieve these levels of innovation.
The tools that you give the team can include information-centric tools, such as big data tools that can help them understand their market better, understand their product better. Whatever it is, they need to do their jobs well. You see this pattern at innovative companies, like Apple. On one hand, obviously, they have very innovative teams, because they come out with these very innovative products. You know the iPad - nobody knew they wanted one and then the next day everybody wanted one and then the day after that everybody had one. It took about three days.
That's a sign of a disruptive innovation, right? It disrupted the market, and now all of the other vendors are scrambling trying to come up with their own tablets, and it happened in a very short amount of time. Well, on the one hand, if they had a culture that was all about "faster, better, cheaper," and their executives were simply trying to drive cost out of their operations, they never would have come up with that. Two, it's not like they had some sort of innovation meeting today and all these hipsters come in and the boss says, "Just go try anything and bring back a winner." And they're just like "Let's do the iPad!" It's like, "Okay, that's good." Well obviously they didn't do that either, they had a lot of information, a lot analysis about customer behaviors, price points, technology capabilities, the technology road maps of their component parts, and all this different stuff. But they still had an innovative team that was allowed to disrupt. That was disrupted, and was allowed to disrupt. That enables a company like Apple, or any other company who essentially lives and breathes innovation to get that innovation right. Even so, there's always risk. Disruption always leads to risk and innovation doesn't always succeed. In fact, it more often fails than it succeeds. Ebay is filled with innovative products that nobody wanted. For every iPad there's a dozen Microsoft bots out there that didn't go anywhere.
Paul Preiss: Is there anything specifically advice-wise, that you'd like to give architects and our audience in terms of where they should be putting their focus? Thoughts that you might have for them in their practice?
Jason: This is a good time for a plug, I guess. You know I do quite a bit of writing, so you can find me on Forbes and on Wired, as well as my bi-weekly Cortex newsletter which you can find on Sys-Con as well as at my website at Intellyx.com. I'm also putting together an architecture course called Bloomberg Agile Architecture. That's in the works, I expect to be running in 2015, and that covers essentially everything we talked about and more.
Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.
Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Certification Course, around the world.
Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.