The future of work, and money
Seems lots of people these days are writing about ‘the future of work’ – and even putting some of that thinking into practice, too. But is that thinking going anything like deep enough? Hmm… – not sure about that… So…
Search Results for: business model
The Microservices Pattern
For those of us that have been practicing SOA for over a decade, it’s surprising that there’s so much interest in microservices. In fairness microservices don’t look like the vendor play that was early SOA in the early noughties. But experienced SOA pr…
The Microservices Pattern
For those of us that have been practicing SOA for over a decade, it’s surprising that there’s so much interest in microservices. In fairness microservices don’t look like the vendor play that was early SOA in the early noughties. But experienced SOA pr…
Architects, It’s Your Time
For decades, CIOs have been fighting for a seat at the executive table. Fighting to be heard, fighting to be a trusted advisor to the CEO, fighting to be regarded as a true C-level participant. It hasn’t been until the last few years that cybersecurity breaches, the sprint toward business digitization, the emphasis on the customer experience and a service-driven economy have thrust the CIO into the spotlight.
In many of these cases, CIOs are lucky to have really smart people backing them up along the way. Enterprise architects (EAs) have typically been the CIO’s right-hand man (or woman), fighting alongside their boss to have their strategic insights heard and their version of innovation understood. Now that digitization is widely recognized as being essential to innovation, growth and the capacity to readily compete, CIOs are well on their way to becoming firmly embedded in charting the direction of the business. This should serve as a clarion call to all EAs. It’s your time – CIOs and other leaders are looking to you.
In a recent Wired article, Jason Bloomberg encouraged Chief Digital Officers to “invite enterprise architects to the digital party.” While we’d certainly agree that enterprise architects need to be connected to every branch and stakeholder in the organization – the CEO, CFO, CIO (of course), CDO, etc. – and provide a unique value to each, we’re not convinced they need to wait for their formal invitation to arrive. A few words of advice to architects that will ensure their visibility, effectiveness and ability to carpe diem:
Know your allies and stand on their shoulders. Although much is being made about the digital transformation of the business, let’s be honest – this is the net evolution of something that has been happening for quite some time. A new-fangled Chief Digital Officer can certainly be a valuable relationship to nurture, but remember to dance with the one that brought you. In many companies, it’s the CIO that is your most longstanding ally. They can ingratiate you with the CDO and lend proven, reliable advocacy to your work. We’re not saying it’s a territory war, but it’s important to be aware of where your strongest connections exist.
Be confident in your expertise. Not everyone will understand what you do. Some people might see you as a geek, like the picture that Bloomberg paints in his piece. But none of that matters, because you’re delivering intelligence that counts and offering a path to real business results. It may take some explaining, but we’ve never seen a case where the light bulb didn’t eventually go off for executives looking to understand the purpose and impact of EA. Go about solving problems, not worrying about evangelizing the tools of your trade under the pretense that people need to understand them in order to trust your contributions.
We like the way that Joe McKendrick describes your role in a recent ZDNet post, with a tip of the hat to John Zachman. Zachman postulates that enterprise architects should be like doctors diagnosing ailments: “The fundamental problem in the enterprise community is nobody is doing the diagnosis, they’re just taking x-rays. If people think that enterprise architecture is a practice of building models, that’s like taking x-rays. What the enterprise architect ought to be doing is reading the models, figuring out what the problem is, then prescribing three, or five, or 20 possible solutions.” Seize the moment to be a figurative doctor.
Evolve the EA terminology. It’s time to turn the page and start talking about what EAs provide in a way that everyone understands. At Troux, we’ve taken to calling it enterprise intelligence because we think it more accurately represents the results that come out of our solutions. Bloomberg calls the EA team the Center of Digital Excellence (CODE); that’s pretty catchy too. Whatever it takes to help business leaders understand that you’re up to speed with the business and in lockstep with business objectives. Don’t let nomenclature drag you down.
At a baseline, don’t sit back and wait for an invitation. Take action, step up to the table and prove that you can help steer the business in a positive, profitable direction. It’s the era of the connected enterprise. Decisions you inform and help make for one part of the business ripple throughout the entire organization, with their impacts felt far and wide. It’s time for EAs to seize the moment and show how they can help diagnose and solve the next wave of digital business challenges. It’s your time.
Check out this short video and download our whitepaper, The Power of Enterprise Intelligence, to learn more about how our solutions help decision-makers take a step back to see the big picture to understand exactly where they should be investing in their business.
All Data as a Service (DaaS/BDaaS) – Who’s Your D-a-a-S Enabler?
That’s where we’re headed, inexorably – you’d like to know what’s going on with your systems, what your customers or constituents need, or perhaps the latest metrics concerning device utilization trends during business events. And, you’d like this information (all of it, or lots of it) right now, in an easily consumable, visual, semantically-relevant way – to share with your community and to be automatically (or easily) ingested by your other systems or analysis tools. Secure & compliant, fast, portable, standardized if necessary, high quality.
But most of all, you’d like to pay only for the data and the way it’s delivered to you – not for a bunch of information technology products and services, hardware and software. You want data-as-a-service, as a consumer; i.e. explicit data units delivered via affordable service units. (Note the service deployment method might include Database-as-a-Service, i.e. DBaaS).
Or – you’re on the other side – you want to actually build the DaaS capability, to offer DaaS (or, perhaps a better term is a “Data Sharing Service” ) to your constituents or customers – as a provider.
There are three primary and distinct roles to consider, whether you’re building or buying DaaS – regardless of the type or characteristics of data that’s being exchanged; big data, open data, fast data, IoT/IoE data, metadata, microdata, multimedia content, structured, non-structured, semi-structured…ALL DATA.
- The DaaS Consumer – who needs not only to acquire data from somewhere (in a way that shields them from the underlying technology concerns), but also then may use it to develop information apps and services, or repackage the data to share further with others. The consumer assigns and realizes value from the service.
- The DaaS Provider – who actually builds, markets and operates the business service and categorized storefront (or catalog), and brokers or stewards the data quality & availability, data rights, licenses and usage agreements between the consumers and the original data owners. The provider creates, shapes and deploys the opportunities for value-enablement of specific data assets.
- IT Services Management – who design, implement and operate the information and data management infrastructure the DaaS Provider relies upon – and manage the IT component and services portfolio this infrastructure includes. For example the databases, virtualization technologies, data access services, storage and middleware capabilities. (Note that “IT Services Management” may be a wholly 3rd-party role, as well as a role within the DaaS Consumer or Provider organizations – there may be 3 or more IT Services Management domains).
There’s also a less distinct, more broadly relevant role – the DaaS Enabler. a.k.a. the “Enterprise Architect”, which can be a person, a role, or an organizational capability. The EA scope includes a heavy focus on enterprise “universal” information management and governance, infused (particularly in the Public Sector) with the currently vogue philosophies of SOA, Open Data, Mobility, Privacy-by-Design (PbD) and Cloud Computing. (Note that DaaS does not have to be delivered via a “cloud” deployment model – it’s equally-applicable delivered as a private data services virtualization platform, for example).
Information management includes the entire lifecycle of “information as an asset” capabilities in an enterprise, and into the stakeholder ecosystem – from the data sources, their ingest and “staging/data quality”, to storage in various repositories and access via information & data services, user interfaces and ultimately information-sharing and digital engagement services. (See more of Oracle’s “Enterprise Information Architecture” ).
The DaaS Enabler (as a person) might be known by other titles, like Chief Data Officer, Chief Information Officer, DaaS Architect, Information Architect – maybe even Chief Innovation Officer (focusing on data assets); regardless of the title, the experience and scope of attention is as mentioned above, coordinated across all three service roles. EA skills are essential, because DaaS enablement includes people, processes, technology and information concerns.
Each service role (Consumer, Provider, IT Management) benefits from the DaaS Enabler, particularly given the fact that the maximum value to be realized by each role’s investment in effort and resources – is collaboratively dependent on the others, and dependent on acknowledgement of proven, trusted, pragmatic enterprise architecture principles.
Oracle is an example of a DaaS Provider – empowering businesses and public sector organizations (i.e. DaaS Consumers) to “use data as a standalone asset and connect with partner data to make smarter decisions. Oracle DaaS is a service in Oracle Cloud that offers the most variety, scale, and connectivity in the industry, including cross-channel, cross-device, and known and anonymous data.”
Oracle is also a DaaS Enabler – as an organizational capability, for DaaS Consumers, Providers and IT Services Management. This includes people (Enterprise Architects, supporting organizations and communities), processes (DaaS engineering, deployment and operations models, case studies, tools and business services), technology (DaaS information and device technologies, tools and platforms, hardware and software) and information (data assets, reference architectures, knowledge capital).
Creating or using Data-as-a-Service (DaaS), Big Data-as-a-Service (BDaaS), or any other DaaS initiative, exposed to the public or entirely within your enterprise? Identify your DaaS Enabler(s).
All Data as a Service (DaaS/BDaaS) – Who’s Your D-a-a-S Enabler?
There are three primary and distinct roles to consider, whether
you’re building or buying DaaS – regardless of the type or
characteristics of data that’s being exchanged; big data, open data,
fast data, IoT/IoE data, metadata, microdata, multimedia content,
structured, non-structured, semi-structured…ALL DATA.
The DaaS Consumer – who needs not only to acquire data from
somewhere (in a way that shields them from the underlying technology
concerns), but also then may use it to develop information apps and
services, or repackage the data to share further with others. The
consumer assigns and realizes value from the service.
The DaaS Provider – who actually builds, markets and
operates the business service and categorized storefront (or catalog),
and brokers or stewards the data quality & availability, data
rights, licenses and usage agreements between the consumers and the
original data owners. The provider creates, shapes and deploys the
opportunities for value-enablement of specific data assets.
IT Services Management – who design, implement and operate
the information and data management infrastructure the DaaS Provider
relies upon – and manage the IT component and services portfolio this
infrastructure includes. For example the databases, virtualization
technologies, data access services, storage and middleware capabilities.
(Note that “IT Services Management” may be a wholly 3rd-party role, as
well as a role within the DaaS Consumer or Provider organizations –
there may be 3 or more IT Services Management domains).
There’s also a less distinct, more broadly relevant role – the DaaS Enabler.
a.k.a. the “Enterprise Architect”, which can be a person, a role, or an
organizational capability. The EA scope includes a heavy focus on
enterprise “universal” information management and governance, infused
(particularly in the Public Sector) with the currently vogue
philosophies of SOA, Open Data, Mobility, Privacy-by-Design (PbD)
and Cloud Computing. (Note that DaaS does not have to be delivered via a
“cloud” deployment model – it’s equally-applicable delivered as a
private data services virtualization platform, for example).
Microservices Unplugged
Given my (well-known and enduring) interest in all aspects of services, I have followed Martin Fowler’s writing on microservices. But I will admit I always found the original paper more confusing than insightful. And in my client work I have resisted the temptation to use a microservices pattern, for precisely the reason that it would more than likely confuse. So I was interested to see the book Building Microservices by Sam Newman published last month, particularly as Newman is part of the Thoughtworks stable, which presumably means it is authoritative.
Right off the bat, Newman advises that we should “think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile Software development”. These analogies are very interesting because my expectation was that microservices is a pattern. So I might infer that microservices is a set of process techniques as opposed to an architectural approach. Yet in the book, Newman clearly includes some elements of concept model and architecture as well as process and organization.
Probably the biggest weakness of Newman’s book is the absence of a coherent reference model. He discusses a series of heuristics such as:
– Microservices are small, autonomous services that work together.
– With high cohesion.
– Gather those things that change for the same reason, and separate those things that change for different reasons.
– Using business boundaries.
– How small is small? Could be written in 2 weeks; small enough and no smaller; can be managed by a small team
– Separate entity. All communications between services are network calls. Decoupled. Minimum dependency.
– We need to think about what our services expose, and what they should allow to be hidden. If there is too much sharing our consuming services become coupled to internal representations.
And these are mostly useful principles, but are most unlikely to guide a consistent approach. Given Martin Fowler’s involvement, I would have expected at least some good patterns. But mature SOA needs a defined concept model, like CBDI-SAE, SOA-RM etc.
This lack of clarity is fundamental. Many organizations treat operations as services, and they typically end up with thousands of services. They will be confused by the very term microservice because they already have what they perceive as small services. Perhaps the term microservice has been chosen because of the ubiquitous use of the ITIL service, which undoubtedly means monolith. Most mature SOA organizations define services and operations as a primary technique to establish cohesion guided by reference models such as SOA-RM and CBDI-SAE. Just as important is the clarity and precision around specifications or contracts and what is exposed to consumers (APIs) and providers. Yet the book contains nothing on the subject of rich service specification or contract as the primary means of achieving implementation independence and business alignment. Organizations adopting microservices will need a defined reference model. Without that there will be architecture governance by personal opinion. I wonder how Thoughtworks advise their clients in this area?
The book contains some quite general advice on business capability based decomposition – which is a tried and tested method of defining services. However there is little or no advice on what a well-formed business capability is, it’s characteristics and governance considerations. In my experience this is an area for considerable confusion; the business capability concept is so well known, but little understood, it’s an accident waiting to happen. And as for the relationship between capability and service, there’s no model provided, and more importantly, the granularity of a business capability service is likely to be non-trivial.
Similarly there’s no guidance on types of service. Do all services contain a mix of channel, process, business and data behaviors? Which you might expect given the explicit advice to gather those things that change for the same reason, and separate those things that change for different reasons.
The one area that might be helpful is the concept that microservices are highly autonomous, and a capability cluster of services would be a unit of deployment. But sadly for Newman, this is an idea that I and my colleagues worked on and popularized nearly 20 years ago. We called it Component Based Development, and the concept was closely allied to Rich Service Specifications which enforced the component boundaries, a concept that seems to have escaped him.
Once upon a time I had expected there to be a microservice pattern. But having read the book, all I see is a set of established ideas being rehashed in a very superficial manner, under a new name; with many key concepts missing or misunderstood. Apparently there is a lack of consensus on how to do SOA well. That failure of SOA is caused by vendors’ products, issues with granularity or picking wrong places to split a system. These assessments of the problem illustrate the lack of understanding of the author and his colleagues. Yes, there have been SOA failures, but mostly they have arisen through a) a focus on integration technology not business, or b) lack of reference model, reference architecture and governance. As an aside, in mature SOA we don’t consider “places to split a system”; we define the scope of a service using well defined heuristics and techniques that vary by type of service. To claim therefore that microservices is the answer to problems with SOA is downright disingenuous. And given the amount of hype I see about the topic generated by supposedly responsible organizations such as Thoughtworks and Gartner, that’s downright irresponsible. Disappointing.
Public Domain information on Mature SOA architecture and delivery practices
——————————————————————————————
Book reference: Building Microservices by Sam Newman
Microservices Unplugged
Given my (well-known and enduring) interest in all aspects of services, I have followed Martin Fowler’s writing on microservices. But I will admit I always found the original paper more confusing than insightful. And in my client work I have resisted the temptation to use a microservices pattern, for precisely the reason that it would more than likely confuse. So I was interested to see the book Building Microservices by Sam Newman published last month, particularly as Newman is part of the Thoughtworks stable, which presumably means it is authoritative.
Right off the bat, Newman advises that we should “think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile Software development”. These analogies are very interesting because my expectation was that microservices is a pattern. So I might infer that microservices is a set of process techniques as opposed to an architectural approach. Yet in the book, Newman clearly includes some elements of concept model and architecture as well as process and organization.
Probably the biggest weakness of Newman’s book is the absence of a coherent reference model. He discusses a series of heuristics such as:
– Microservices are small, autonomous services that work together.
– With high cohesion.
– Gather those things that change for the same reason, and separate those things that change for different reasons.
– Using business boundaries.
– How small is small? Could be written in 2 weeks; small enough and no smaller; can be managed by a small team
– Separate entity. All communications between services are network calls. Decoupled. Minimum dependency.
– We need to think about what our services expose, and what they should allow to be hidden. If there is too much sharing our consuming services become coupled to internal representations.
And these are mostly useful principles, but are most unlikely to guide a consistent approach. Given Martin Fowler’s involvement, I would have expected at least some good patterns. But mature SOA needs a defined concept model, like CBDI-SAE, SOA-RM etc.
This lack of clarity is fundamental. Many organizations treat operations as services, and they typically end up with thousands of services. They will be confused by the very term microservice because they already have what they perceive as small services. Perhaps the term microservice has been chosen because of the ubiquitous use of the ITIL service, which undoubtedly means monolith. Most mature SOA organizations define services and operations as a primary technique to establish cohesion guided by reference models such as SOA-RM and CBDI-SAE. Just as important is the clarity and precision around specifications or contracts and what is exposed to consumers (APIs) and providers. Yet the book contains nothing on the subject of rich service specification or contract as the primary means of achieving implementation independence and business alignment. Organizations adopting microservices will need a defined reference model. Without that there will be architecture governance by personal opinion. I wonder how Thoughtworks advise their clients in this area?
The book contains some quite general advice on business capability based decomposition – which is a tried and tested method of defining services. However there is little or no advice on what a well-formed business capability is, it’s characteristics and governance considerations. In my experience this is an area for considerable confusion; the business capability concept is so well known, but little understood, it’s an accident waiting to happen. And as for the relationship between capability and service, there’s no model provided, and more importantly, the granularity of a business capability service is likely to be non-trivial.
Similarly there’s no guidance on types of service. Do all services contain a mix of channel, process, business and data behaviors? Which you might expect given the explicit advice to gather those things that change for the same reason, and separate those things that change for different reasons.
The one area that might be helpful is the concept that microservices are highly autonomous, and a capability cluster of services would be a unit of deployment. But sadly for Newman, this is an idea that I and my colleagues worked on and popularized nearly 20 years ago. We called it Component Based Development, and the concept was closely allied to Rich Service Specifications which enforced the component boundaries, a concept that seems to have escaped him.
Once upon a time I had expected there to be a microservice pattern. But having read the book, all I see is a set of established ideas being rehashed in a very superficial manner, under a new name; with many key concepts missing or misunderstood. Apparently there is a lack of consensus on how to do SOA well. That failure of SOA is caused by vendors’ products, issues with granularity or picking wrong places to split a system. These assessments of the problem illustrate the lack of understanding of the author and his colleagues. Yes, there have been SOA failures, but mostly they have arisen through a) a focus on integration technology not business, or b) lack of reference model, reference architecture and governance. As an aside, in mature SOA we don’t consider “places to split a system”; we define the scope of a service using well defined heuristics and techniques that vary by type of service. To claim therefore that microservices is the answer to problems with SOA is downright disingenuous. And given the amount of hype I see about the topic generated by supposedly responsible organizations such as Thoughtworks and Gartner, that’s downright irresponsible. Disappointing.
Public Domain information on Mature SOA architecture and delivery practices
——————————————————————————————
Book reference: Building Microservices by Sam Newman
Mastering ArchiMate
This is not your usual architecture book as its title suggests it is about modelling using the ArchiMate notation. The author doesn’t promote any particular tool and concentrates on the notation, which recently underwent a major revision. Whether you are new to ArchiMate or have been using it for some time I think you’ll find […]
Mobility and Cloud Computing and the need for a new security concept
Mobility and Cloud Computing ask for a new approach to structuring and organizing security. The current modern way of doing business and service provisioning is based on openness and agility. This brings the traditional security concept in which an organization … Continue reading →
Mobility and Cloud Computing and the need for a new security concept
Mobility and Cloud Computing ask for a new approach to structuring and organizing security. The current modern way of doing business and service provisioning is based on openness and agility. This brings the traditional security concept in which an organization … Continue reading
The Secret Behind Selecting The Right Enterprise Architecture Tool
Implementing an effective enterprise architecture program is about more than just selecting a tool to aggregate and visualize data. As an EA solutions provider, we talk to a lot of organizations in the early stages of implementation, which gives us a unique, clean-slate perspective on the selection process. Frankly, the most obvious misstep that we see is an emphasis on the functionality of the tool versus what it can ultimately accomplish toward real business success.
Often, when we get into the room with an organization in the evaluation phase, they tell us about how the EA tool(s) they have used in the past delivered little value and poor insights. They want to jump right into the functionality our tools provide as if the functions themselves are the missing puzzle piece. Yes, it’s important to access the metamodel and to be able to load and manage the data repository. But it’s also integral to understand data reports and analytics as well as ensure security and scalability. The tools can almost always collect the data; it’s what you do with the data that creates value. That value can only be measured against goals, so that is typically the first bridge to cross.
Know What You Want To Accomplish
Start by identifying quantifiable business goals that will signify a successful implementation. These goals help define what success looks likes and keep everyone on the same page regarding the desired end result.
What A Quantifiable Business Goal Is NOT:
- Creating models that describe the enterprise architecture.
- Being able to use a particular notation, framework or metamodel construct.
What A Quantifiable Business Goal IS:
- Save $100 million on annual IT operational costs; invest half the savings in business growth.
- Ensure investments and changes directly align with the overall business strategy and that multiple projects are not claiming the same value, resulting in redundant expenses.
- Demonstrate understanding of the economic impact regulatory risks have on business-critical processes.
Arm Yourself to Achieve Value
The success or failure of tool implementation most often has little to do with the tool itself. It’s the organizational and planning aspects – where human error can occur – that are most critical. Every organization has unique variables that factor into their implementation, but we have seen a higher probability of successful selection of platforms and tools when the following are in place:
- Executive sponsorship that mandates execution toward identified goals.
- A clear scope of what success looks like.
- A complete understanding of the stakeholders served by the initiative, as well as the business value to be delivered.
- A high-level roadmap that describes how the business gets from the “as is” to the “to be” model.
- Reliable management structure and processes that coordinate portfolio management activities across all involved business units.
- An acknowledgement that maintaining the required data will involve an organizational shift as well as time investment from those who know and manage the data.
- Proper evaluation of each potential use-case, based on merits and a promise to only execute on those that have a positive return on investment (ROI).
That last point is especially important, because if you can’t work out the ROI, you are in danger of doing the wrong thing and selecting the wrong tool.
Don’t let the list intimidate you; let it guide you. Following it helps you drive business transformation with your stakeholders. The key is to recognize the challenges and find practical ways to overcome them, which is where experience helps.
Learn From Those Who Have Been There Before
Almost as important as the tools themselves are the advisors behind them. Consultants draw from best practices identified through hundreds of engagements to help clients navigate the complex terrain of establishing a successful EA practice, so being comfortable with and confident in them is part of picking the right vendor package. Many of the best consultants were previously EA customers, so they have faced the same challenges and have the foresight to help companies plan for how they can work with data and effectively bridge the gap from tool functionality to underlying business value. It’s important to keep this in mind. When it comes down to it you are not just selecting a tool – you are also selecting the people that stand behind it.
So remember before you select your tool, you need a thought out, formal EA strategy and the reliable experts to help you accomplish it. Remember: The bells and whistles of your EA tools do you no good if they don’t have an established, demonstrable purpose and you lack the trusted advisors that can help you achieve your goals.
Check out whitepaper, The Power of Enterprise Intelligence, to learn more about how our solutions help decision-makers take a step back to see the big picture to understand exactly where they should be investing in their business.
