176591517Unless we re-think Enterprise Architectures (EA), and bring it into alignment with the agile development movement, we may be in for a collision between two cultures.

Here at Info-Tech world headquarters, we are working on a series of project blueprints on agile development (more about that below). I’ve been involved quite a bit in quality reviews of these blueprints and have started thinking about the impact of agile development on Enterprise Architecture. I see the implementation of EA as being at odds with the Agile Manifesto. Here’s the manifesto, in case you haven’t seen it in a while:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Enterprise Architecture, as currently implemented in large organizations, tends to favor the items on the right over the items on the left. The stock in trade of EA consists of processes, tools, comprehensive documentation and creating plans for others to follow. As agile development grows within large organizations, something clearly has to give.

Reinvent, Oppose, or Meet in the Middle?

Can Enterprise Architecture reinvent itself as an agile practice or must it, by its very nature, oppose agile development as yin to its yang? Or should agile and EA meet somewhere in the middle?

Those of us with many years of IT experience sometimes shudder at the thought of the agile manifesto. With the gift of 20/20 hindsight, we look at the tangled mess of systems built in a typical IT shop over the last 30 years and wonder if a little planning might have saved the day. If we were guilty of anything, it was being too responsive to our business users.

Instead of building that fifteenth billing system because the user’s product line was special and needed to launch yesterday, maybe we could have insisted on re-purposing an existing system and saved the company from the burden of duplicate customer databases, nineteen different customer identifiers and revenue reports that don’t reconcile. Do we really want to become even more responsive and adding to the spaghetti that is already strangling the typical IT department in a huge technical debt that soaks up 80% of the budget?

On the other hand, our business users are so fed up with the slow pace of IT that they are taking matters into their own hands and implementing cloud solutions left and right. If we insist on rigorous central planning, we’ll end up managing yesterday’s IT department and wondering where all the new applications went.

The Road to Re-invention

Clearly, we need to re-invent Enterprise Architecture to retain its best features and avoid technical debt while adapting to the new realities of agility and the cloud. How on earth do we do that?

Here are some of my early thoughts:

  • We need to focus on high-level principle statements and vision diagrams that can communicate the essence of our target state quickly. Our audience now consists of people who have grown up with sound bites, infographics and video games. If we can’t communicate to this audience, we are lost before we begin.
  • Our revision cycles have to speed up and adapt. The ponderous Application Development Methodology (ADM) that forms the heart of TOGAF doesn’t cut it anymore. Our architects need to become part of the agile teams, contributing to the development of working software and constantly feeding back to agile EA teams who are actively maintaining the integrity of our target state vision.
  • The various core practices of architecture (business architecture, technical architecture, data architecture etc.) need to be practiced simultaneously in agile sprints, not in sequence.
  • The notion of architecture governance, based on review gates and review boards for large waterfall projects, must be discarded and replaced with a “roll your sleeves up” approach that embeds architects with agile teams so that they can practice governance in real-time. This will avoid costly rework when teams fail to meet standards and adhere to guidelines.
  • The holy grail of a fundamental repository of re-usable artefacts must finally be set to rest. Artefacts rarely, if ever, get re-used and no one ever trusts the state of current documentation as an accurate representation of the actual state of the application. Let’s get over it and be practical.

Please note that I’m not advocating any abdication of EA responsibility. We need a clear central vision of what we’re building to avoid technical debt and ensure that systems mesh together well. However, the way we accomplish this must change with the times. We need to be able to clearly and quickly communicate our vision and become active evangelists for it, contributing to real work as we encourage our team members to do the right things.

Agile Sprint
Click For Infographic

Those Info-Tech project blueprints on agile I mentioned above include Agile Practices that Work. This blueprint is aimed at organizations implementing agile technologies for the first time and is a no-nonsense practical guide to implementing scrum. A second blueprint called Increase the Agile Footprint, currently in production, is focused on optimizing the application of agile methods and gaining momentum in the organization for the roll-out of agile to more projects. The third and final blueprint will be aimed at scaling up agile methods to take on large projects and will be based on the methodology created by Scott Ambler, called Disciplined Agile Development.

We are also thinking about creating a blueprint on this subject of re-inventing EA for the Agile Movement. I welcome your thoughts and experiences. Has anyone out there implemented agile enterprise architecture in some fashion?

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter
big data word cloud
Avoid a big data mess by learning and applying an architectural approach with Info-Tech’s blueprint, Create a Customized Big Data Architecture and Implementation Plan

Big data is moving beyond hype into solutions that are providing real insight and business value. It is no longer the elephant in the room that nobody wants to talk about: it is a growing ecosystem of data, technology, and resources that everyone wants to understand more about, and do something with.

So why is this ecosystem so complex? Well, big data itself is complex: in fact there still isn’t consensus on what it actually is; there is only a set of attributes that try to describe what it is, and even those aren’t consistent across the industry. Our definition of Big Data is “rapidly increasing amounts of data, generated by multiple sources, in many formats; analyzed for new insights.” Essentially a paraphrase of the traditional 3 V’s: Volume, Variety, Velocity – with added aspects of Veracity and Value.

In contrast, traditional data comes from known sources, at controlled volumes, with understandable content. Therefore, it’s no surprise that big data architecture is different from traditional data architecture. Today’s data architects are trying to understand the ecosystem, and deal with the paradigm shift that big data is causing in their knowledge and capabilities in data architecture.

The big differences in big data architecture include:

  • Big data architecture starts with the data itself, taking a bottom-up approach. Decisions about data influence decisions about components that use data.
  • Big data introduces new data sources such as social media content and streaming data.
  • The enterprise data warehouse (EDW) becomes a source for big data, rather than a destination for transactional data.
  • The variety of big and unstructured data requires new types of persistence.
  • Data persistence is horizontal, not vertical.
  • NoSQL is very different from SQL.

Architecture is much more about making decisions than creating specifications. Big data architecture requires decisions in four primary layers:

  1. Data: what kind of data is part of the organization’s big data value chain?
  2. Data Integration: how is the data captured and integrated for analytics?
  3. Data Persistence: how and where does the data need to be stored for analytics?
  4. Data Analytics: what types of analytics does the organization need to perform?

Understanding how the organization wants to leverage big data through selection of a business pattern will help with decisions about data. Data sources, types, and volumes will influence decisions about data integration and persistence technology. How the data is organized and persisted will influence decisions about what types of analysis technology is required.

Setting principles and guidelines about the use of Open Source Software (OSS) vs. vendor solutions can also influence architecture decisions. Given that most of the big data solutions originated out of OSS, the decision to use or not use OSS is a little more difficult than traditional approaches to the problem.

Without a structured approach to big data architecture, organizations could find themselves in a Big Data Mess: they risk their existing data architecture being unable to handle big data, eventually resulting in a failure that could compromise the entire data environment. Also, they risk solutions being picked in an ad hoc manner, which could cause incompatibility issues down the road.

With the rapid change of big data and associated technologies, governance is critical to maintain structure and organization in the big data environment. Big data architecture will help establish the governance structure and boundaries, and anticipate change. An Architectural Review Board and Change Management processes will be very helpful to ensuring the big data architecture continues to work smoothly and effectively into the future.

Avoid a big data mess by learning and applying an architectural approach to big data with Info-Tech’s blueprint, Create a Customized Big Data Architecture and Implementation Plan.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

The cloud is causing the most significant disruption to the IT organization as we know it. The trend to cloud adoption is picking up speed, and as confidence in cloud services and service providers increases, the adoption curve will accelerate. All parts of the in-house IT organization will be affected.

Historically, IT has controlled the hardware and software in the data center, as well as the delivery channels for connecting end users to data center resources. With cloud, IT is increasingly losing control of its role in application selection and development as the business contracts directly with cloud providers for software solutions, using their own OPEX budget.

The ease of procurement, flexibility, scalability, and more predictive time-to-deploy all make cloud services attractive to the business. If IT cannot move faster and show the business what is possible, it will become increasingly marginalized, and will likely be absorbed into the cloud and the business.

The cloud is marking the end of classic IT and the plan-build-run model, as businesses increasingly move away from the traditional “own and operate” approach to IT. IT needs to adopt a new model, enable-integrate-manage, scale down its operations, and re-tool itself with new capabilities to take on new accountabilities.

 

Chart graphic

The key capabilities that will bolster IT’s strategic position within the organization are:

Business Strategy:

  • Building a technology-integrated business strategy rather than a technology strategy based on the business strategy.
  • Enabling business agility and growth.
  • Facilitating the innovation mandate.

Technology Leadership:

  • Understanding how your customers exploit technology in their day-to-day lives.
  • Mastering the capabilities and uncertainties that come with rapidly evolving technologies.
  • Seizing opportunities presented by technology innovation.

Service Management:

  • Developing and managing an efficient and flexible infrastructure.
  • Managing your portfolio of investments in business changes involving IT.
  • Optimizing the value, cost, and risk of IT sourcing arrangements.

Big Data Analytics:

  • Processing, discovering, and analyzing massive data sets for deeper insights and more effective decision making.
  • Tying together multiple big data sources including social graph, intent graph, consumption graph, interest graph, and mobile graph.
  • Enabling real-time self-service business intelligence.

The IT leader needs to lead the IT organization through a transition that will change IT’s focus from mainly projects and operations to facilitating the creation of advanced business capabilities. There will be fewer roles and people in IT, and a more strategic focus. It will not be an overnight transition, but it will happen, and those IT leaders who do not take the lead, will find themselves increasingly disconnected from the organization.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

Mobile phone

There’s no shortage of links and opinions in the blogosphere about how mobile development is critical to your business – come on, we’ve even coined the phrase “Mobile First Development.” Here we go. Let’s embrace a new era in development where mobile is king, desktop is gone, and life works as it was meant to be, right? Not so fast.

The reality is we have legacy applications that drive critical business processes. We have years of experience developing for these “legacy” platforms. We’ve invested time in training, tools, and best practices. Mobile is still young (granted, the velocity of innovation is incredible). Can anyone say we’ve got enough knowledge across the industry to establish sound patterns for mobile enterprise development? Surely you’re not planning to use a consumer-based mobile development model to drive our mobile enterprise strategy. So what now? In a word – pivot. More on that later.

In a manner of speaking, mobile devices are superset devices. They are able to browse websites just like desktops can (I’ll steer clear of the elastic UI discussion to keep us from getting too far off topic). But they also offer more in terms of hardware capabilities that are well-suited to a mobile experience. So there you have it – mobile is just a container that you can use to send and receive information using a web or a native footprint.

As a business, you ought to be thinking about how you can get into mobile with some bottom line in mind. You should be considering how your existing assets (yes, those “legacy” ones) can be repurposed for mobile. Forget the hype around consumer apps. You’re a business. Think this through. Do you absolutely need the hardware capabilities on the device? If not, why go native? Pivot off your existing web development into mobile. If you need native, pivot your web development for the mid and back tiers while providing native hardware capabilities at the UI level. Yes, web services still work on mobile (just set up an appropriate sync cycle for mobile to accommodate the on/off mobile network state).

If you’re headed down the mobile web path, start thinking in terms of horizontal UI, cross form-factor functional testing, and load testing. If you’re considering native app, then don’t forget about feature parity across devices, deployment fragmentation, and support for older apps.

Bottom line is mobile should be embraced by leveraging what you already know. Stop buying into the hype around one, two, click, and app. Instead think strategically and responsibly about future maintenance, augmentation, and quality.

For more information about developing your mobile app program, see Info-Tech’s recent solution set Build a Capable Mobile Program without the Confusion and Frustration.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

covered houseA wise man once said that people who build their houses on a foundation of rock are able to withstand the storms of life. On the other hand, people who build their houses on foundations of sand will be swept away in the storms.

In the IT world of today, data is being bashed by the raging moves to the cloud, mobile computing, and trust issues. Not to mention the tsunami of big data and analytics that is on its way if it hasn’t already hit you. Knowing where your data is, where it came from, and how it is protected are the cornerstones of your data architecture.

Policies and procedures that govern who has access to data, from where access is allowed, how data is sourced and entered, how it is cleansed, how it is used, and when data needs to be archived, are building blocks that make up the foundation. Master data is the mortar that holds the foundation together. If your master data isn’t managed properly with the right mix of stewardship, ownership, and governance: it will disintegrate and the foundation will at risk of collapsing.

As cloudy skies form overhead, the foundation provides the necessary footings (constraints) and walls (boundaries) on which the applications that use corporate data are implemented; providing a solid structure that can withstand the storms of today and tomorrow’s IT disruptors and opportunities.

Don’t let your data and information be swept away. Architect today for change tomorrow and be sheltered from the storm.

To learn more about data architecture, see Info-Tech’s solution set, Develop a Five Year Data Architecture Plan.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter