Tag Archives: Enterprise Architecture
Organizational Change Management and Business Process Re-engineering was the rage in 1990’s. Much of that thinking still persists today but it is no longer sufficient for the kinds of transformations that organizations need to accomplish on an ongoing basis today. A modern business transformation is data driven, global in nature, crosses functional boundaries, and changes behavior at multiple levels of the organization. To address these needs organizations need to adopt a business-led enterprise-wide planning capability. (more…)
This post is about Markitecture – a combination of marketing and architecture for IT solutions. Whether it is on a whiteboard or a PowerPoint slide, markitecture is typically a one page informal illustration of a system’s structure and interactions. It shows the major components, their relationships and has a few carefully selected labels and text that describes the design philosophies embodied in it. While it is easy to create and there value in a markitecture, it doesn’t qualify as Architecture and it isn’t sufficient for solving the real underlying problems. (more…)
One of THE biggest challenges in companies today is complexity. To be more specific, unnecessary complexity resulting from silo behaviors and piece-meal point solutions. Businesses today are already extremely complex with the challenges of multiple products, multiple channels, global scale, higher customer expectations, and rapid and constant change, so we certainly don’t want to make the IT solutions more complex than they need to be. That said, I’m on the side of NO we don’t need a CSO as this blog recently surveyed its readers. We just need a business architecture practice that does what it’s supposed to. (more…)
Enterprise IT is in a state of constant evolution. As a result, business processes and technologies become increasingly more difficult to change and more costly to keep up-to-date. The solution to this predicament is an Enterprise Architecture (EA) process that can provide a framework for an optimized IT portfolio. IT Optimization strategy should be based on a comprehensive set of architectural principles which ensure consistency and make IT more responsive, efficient, and economical.
The rationalization, standardization, and consolidation process helps organizations understand their current EA maturity level and move forward on the appropriate roadmap. As they undertake the IT Optimization journey, the IT architecture matures through several stages, leveraging IT Optimization Architecture Principles to attain each level of maturity.
Level 1: The first step involves helping a company develop its architecture vision and operating model, with attention to cost, globalization, investiture, or whatever is driving the company strategically. Once that vision is in place, enterprise architects can guide the organization through an iterative process of rationalization, consolidation, and eventually shared-services and cloud computing.
Level 2: The rationalization exercise helps an organization identify what standards to move towards as they eliminate the complexities and silos they have built up over the years, along with the specific technologies that will help them get there.
Depending on the company, Rationalization could start with a technical discussion and be IT-driven; or it could start at a business level. For example, a company might have distributed operations across the globe and desire to consolidate and standardize its business processes. That could drive change in the IT portfolio. Or a company that has gone through mergers and acquisitions might have redundant business processes to rationalize.
Rationalizing involves understanding the current state of an organization’s IT portfolio and business processes, and then mapping business capabilities to IT capabilities. This is done by developing scoring criteria to analyze the current portfolio, and ultimately by deciding on the standards that will propel the organization forward. Standards are the outcome of a rationalization exercise.
Standardized technology represents the second level of EA maturity. Organizations at this level have evolved beyond isolated independent silos. They have well-defined corporate governance and procurement policies, which yields measurable cost savings through reduced software licenses and the elimination of redundant systems and skill sets.
Level 3: Consolidation entails reducing the footprint of your IT portfolio. That could involve consolidating the number of database servers, application servers and storage devices, consolidating redundant security platforms, or adopting virtualization, grid computing, and related consolidation initiatives.
Consolidation may be a by-product of another technology transformation, or it may be the driver of these transformations. But whatever motivates the change, the key is to be in alignment with the overall business strategy. Enterprise architects understand where the business is going so they can pick the appropriate consolidation strategy.
Level 4: One of the key outcomes of a rationalization and consolidation exercise is the creation of a strategic roadmap that continually keeps IT in line with where the business is going.
Having a roadmap is especially important when you move down the path to shared services and cloud computing. For a company that has a very complex IT infrastructure and application portfolio, having a strategic roadmap helps the organization to move forward incrementally, minimizing risk, and giving the IT department every opportunity to deliver value to the business.
Knowing business’s trends and needs change frequently, why is it that we plan multi-year IT-driven roadmaps?
Understandably, IT managers have honed their skills in working with the line to predict business needs. They have learned to spend money and time wisely and to have the right infrastructure in place to meet the business’ needs. Whether it is launching in a new market, implementing a new technology, or one of many other areas where IT can help its firm find a competitive advantage.
Not so long ago, IT was so complex and unwieldy that it needed specially-trained professionals to source, build, and run almost every aspect of it, and when line managers had scant understanding which technology would suit their activities best, making a plan based on long-term business goals was a good one.
Today, we talk of IT as a utility, just like electricity, you press a button, and IT turns “on.” However that is not the case, the extent to which IT has saturated the day-to-day business life means they are better placed to determine how technology should be used to achieve the company’s objectives.
In the next five years, the economic climate will change, customer preferences will shift, and new competitors will threaten the business. Innovations in technology will provide new opportunities to explore, and new leadership could send the firm in a new direction. While most organizations have long-term growth targets, their strategies constantly evolve.
This new scenario has caused those in the enterprise architecture (EA) function to ask whether long-term road mapping is still a valuable investment.
EAs admit that long-term IT-led road mapping is no longer feasible. If the business does not have a detailed and stable five-year plan, these architects argue, how can IT develop a technology roadmap to help them achieve it? At best, creating long-term roadmaps is a waste of effort, a never-ending cycle of updates and revisions.
Without a long-range vision of business technology demand, IT has started to focus purely on the supply side. These architects focus on existing systems, identifying ways to reduce redundancies or improve flexibility. However, without a clear connection to business plans, they struggle to secure funding to make their plans a reality.
IT has turned their focus to the near-term, trying to influence the small decisions made every day in their organizations. IT can have greater impact, they believe, if they serve as advisors to IT and business stakeholders, guiding them to make cost-efficient, enterprise-aligned technology decisions.
Rather than taking a top-down perspective, shaping architecture through one master plan, they work from the bottom-up, encouraging more efficient working by influencing the myriad technology decisions being made each day.
The current trend is that new types of data and new types of physical storage are changing all of that.
When I got back from my trip I found a TDWI white paper by Philip Russom that describes the situation very well in a white paper detailing his research on this subject; Evolving Data Warehouse Architectures in the Age of Big Data.
From an enterprise data architecture and management point of view, this is a very interesting paper.
- First the DW architectures are getting complex because of all the new physical storage options available
- Hadoop – very large scale and inexpensive
- NoSQL DBMS – beyond tabular data
- Columnar DBMS – very fast seek time
- DW Appliances – very fast / very expensive
- What is driving these changes is the rapidly-increasing complexity of data. Data volume has captured the imagination of the press, but it is really the rising complexity of the data types that is going to challenge architects.
- But, here is what really jumped out at me. When they asked the people in their survey what are the important components of their data warehouse architecture, the answer came back; Standards and rules. Specifically, they meant how data is modeled, how data quality metrics are created, metadata requirements, interfaces for data integration, etc.
The conclusion for me, from this part of the survey, was that business strategy is requiring more complex data for better analyses (example: realtime response or proactive recommendations) and business processes (example: advanced customer service). This, in turn, is driving IT to look into more advanced technology to deal with different data types and different use cases for the data. And finally, the way they are dealing with the exploding complexity was through standards, particularly data standards. If you are dealing with increasing complexity and have to do it better, faster and cheaper, they only way you are going to survive is by standardizing as much as reasonably makes sense. But, not a bit more.
If you think about it, it is good advice. Get your data standards in place first. It is the best way to manage the data and technology complexity. …And a chance to be the driver rather than the driven.
I highly recommend reading this white paper. There is far more in it than I can cover here. There is also a Philip Russom webinar on DW Architecture that I recommend.
The article provided the following recommendations when talking to teenagers:
1. Talk with them and not at them.
2. Ask questions that go beyond “yes” or “no” answers to prompt more developed conversation.
3. Take advantage of time during car trips to talk with your teen.
4. Make time for sporting and school events, playing games, and talking about current events.
Let’s see how these recommendations could be applied:
1. Talk to them and not at them
Ask your teenager the following question – Have you ever heard about Enterprise Architecture?
“It is a way to help a company understand its customers and how its products are made and sold. It helps managers improve the way the company works and how technology is used to help people do a better job”.
2. Ask questions that go beyond “yes” or “no” answers to prompt more developed conversation.
Ask your teenager the following question: What do you want to do when you grow up? – Depending on the answer you may need to customize the text below.
“Enterprise Architecture helps you understand the needs of (the industry selected by your teenager). It will then tell you the typical activities that employees do and the systems and technologies that are used to simplify those activities”.
3. Take advantage of time during car trips to talk with your teen.
Imagine the following scenario with your teenager – we can do the following exercise. Let’s assume your teenager wants be part of an advertising agency for the entertainment industry.
“We should count the number of billboards on the side of the road and note how many are movie advertisements. I am interested in your opinion of which advertising style sparks your interest in a specific movie”.
“If we do that we can then discuss the different activities that are required in making that advertising material and how to make the images speak to you. Enterprise Architecture also does that. It helps you understand the activities required in any business, step by step, allowing you to create templates or graphics that represent any industry”.
4. Make time for sports and school events, play games, and talk about current events.
Another sample conversation to support this recommendation could be:
“Let’s go to the movies this week. Once you select one you would like to see, see if you can identify why you choose this particular movie over the other ones. If you think of the billboards that we saw, can you remember what motivated or influenced you?. We can understand together what the designers of those images were creating in the visual experience. Perhaps you have new ideas or suggestions on how they could have done it better? With the help of Enterprise Architecture companies identify more efficient activities to generate more business”.
After researching the topic I realized that we could apply these recommendations to share Enterprise Architecture with our business partners. Perhaps the readers of this blog can help by using these recommendations with their teenagers at home to explain the basic concepts of Enterprise Architecture and collectively create a simpler way to talk about Enterprise Architecture.
Just exactly how do your move from a “Just a Bunch of Data” (JBOD) architecture to a coherent enterprise data architecture?
The white paper, “The Great Rethink: Building a Highly Responsive and Evolving Data Integration Architecture” by Claudia Imhoff and Joe McKendrick provides an interesting view of what such an architecture might look like. The paper describes how to move from ad hoc Data Integration to an Enterprise Data Architecture. The paper also describes an approach towards building architectural maturity and a next-generation enterprise data architecture that helps organizations to be more competitive.
Organizations that look to compete based on their data are searching for ways to design an architecture that:
- On-boards new data quickly
- Delivers clean and trustworthy data
- Delivers data at the speed required of the business
- Ensures that data is handled in secure way
- Is flexible enough to incorporate new data types and new technology
- Enables end user self-service
- Speeds up the speed of business value delivery for an organization
In my previous blog, Digital Strategy and Architecture, we discussed the demands that digital strategies are putting on enterprise data architecture in particular. Add to that the additional stress from business initiatives such as:
- Supporting new mobile applications
- Moving IT applications to the cloud – which significantly increases data management complexity
- Dealing with external data. One recent study estimates that a full 25% of the data being managed by the average organization is external data.
- Next-generation analytics and predictive analytics with Hadoop and No SQL
- Integrating analytics with applications
- Event-driven architectures and projects
- The list goes on…
The point here is that most people are unlikely to be funded to build an enterprise data architecture from scratch that can meet all these needs. A pragmatic approach would be to build out your future state architecture in each new strategic business initiative that is implemented. The real challenge of being an enterprise architect is ensuring that all of the new work does indeed add up to a coherent architecture as it gets implemented.
The “Great Rethink” white paper describes a practical approach to achieving an agile and responsive future state enterprise data architecture that will support your strategic business initiatives. It also describes a high level data integration architecture and the building blocks to achieving that architecture. This is highly recommended reading.
Also, you might recall that Informatica sponsored the Informatica Architect’s Challenge this year to design an enterprise-wide data architecture of the future. The contest has closed and we have a winner. See the site for details, Informatica Architect Challenge .
What is digitization?
It can take many forms. Here are a few types of digitization of business and examples:
|Products that add digital components||Sports equipment with sensors for immediate feedback|
|Products sold through digital channels||Conde Nast magazines|
|“Solutions” that are assembled and delivered in digital channels||USAA Insurance|
|Products that are entirely digital||Apple iTunes, eSurance, PayPal, Google|
|Companies monetizing their data||Healthcare clinical data|
The really interesting thing about digitization that you can see from some of the examples above is that it enables new competition to enter your space and competitors to leap industry boundaries. The concept of “barriers to entry” itself is eroding.
The Impact of Digitization on IT
Some interesting facts from MIT CISR’s research with Boards of Directors on digitization jumped out at me:
- Board members estimate that 32% of company’s revenues are under threat from digital disruption. This is a really stunning number when you think about it.
- Half of Board members believe that their board’s ability to oversee the strategic use of IT is “less than effective.”
- 26% of Boards hired consultants to evaluate major projects or the IT unit.
- 60% of Boards want to spend more time on digital issues next year.
The Impact of Digitization for Architects?
It boils down to two things:
- Architects need to deliver a digital platform to enable business agility in a time of increasing competition and disruption. This includes standardization around business processes, data, and the platform.
- Architects need to get more proactive in the strategy process for their organizations both in terms of the platforms and architecture and in terms of a general understanding of the challenges and opportunities that arise from digital disruption.
For more on enterprise data architecture, best practices and reference architectures see the eBook: Think “Data First” to Drive Business Value
Just last week, I visited a client for whom I had been consulting on-and-off for several years. On the meeting room wall, I saw their Enterprise Architecture portfolio, beautiful graphically designed and printed on a giant sheet of paper. My host proudly informed me how much she enjoyed putting that diagram together in 2009.
I jokingly reminded her of the famous notion of “art for art’s sake”; which is an appropriate phrase to describe what many architects are doing when populating frameworks. Indeed, when we refer to Enterprise Architecture, we must remember that the term ‘architecture’ is, itself, a metaphor.
In a tough economy, when competition is increasingly global and marketplaces are shifting, this ability to make tough decisions is going to be essential. Opportunities to save costs are going to be really valued, and architecture invariably helps companies save money. The ability to reuse, and thus rapidly seize the next related business opportunity, is also going to be highly valued.
The thing you have to be careful of is that if you see your markets disappearing, if your product is outdated, or your whole industry is redefining itself, as we have seen in things like media, you have to be ready to innovate. Architecture can restrict your innovative gene, by saying, “Wait, wait, wait. We want to slow down. We want to do things on our platform.” That can be very dangerous, if you are really facing disruptive technology or market changes.
Albert Camus wrote a famous essay exploring the Sisyphus myth called “The Myth of Sisyphus,” where he reinterpreted the central theme of the myth. Similarly, we need to challenge the myths of Enterprise Architecture and enterprise system/solution architecture in general – not meekly accept them.
IEEE says, “A key premise of this metaphor is that important decisions may be made early in system development in a manner similar to the early decision-making found in the development of civil architecture projects.”
Keep asking yourself, “When is what we built that’s stable actually constraining us too much? When is it preventing important innovation?” For many architects, that’s going to be tough, because you start to love the architecture, the standards, and the discipline. You love what you’ve created, but if it isn’t right for the market you’re facing, you have to be ready to let it go and go seize the next opportunity.
The central message is as follows: ‘documenting’ architecture in various layers of abstraction for the purposes of ‘completeness’ is plainly ridiculous. This is especially true when the effort to produce the artifacts takes such an amount of time as to make the whole collection obsolete on completion.