Author: Bunny Tharpe

Categories
erwin Expert Blog

Overcoming Teething Problems in Enterprise Architecture

Historically, the teething problems in enterprise architecture have prevented it from realising its full potential. However, the uptick in data-driven business has made the practice essential, meaning organizations are looking for an enterprise architecture approach that works best for them.

Although they might not always be immediately obvious to the outsider, the value of Enterprise Architects to EAs and even many CIOs is clear. The practice has long been one of the best drivers of business transformation, and IT/business alignment.

Yet over the years, a number of studies indicate hurdles in the early stages of Enterprise Architecture maturity that can stop businesses progressing further with the scheme.

Take Gartner for example. In a 2007 survey from the world renowned tech analyst, Gartner found that 40% of Enterprise Architecture initiatives would be stopped. A later survey (2015) indicates at least a degree of accuracy in the former, as it showed 70% of businesses were looking to either start, or restart an Enterprise Architecture programme.

It seems as if, although businesses are aware of the advantages of an EA practice, actually introducing one can be difficult.

With that said, this blog will covers things to consider when implementing an EA practice to avoid the historical problems in enterprise architecture initiatives and ensure it’s success going forward.

Problems in Enterprise Architecture: EA Needs Time

Businesses that adopt EA on a whim – in that they know they should be doing in EA, but don’t fully understand why – will likely run into this issue.

We must understand that Enterprise Architecture is far from an overnight fix. In fact, it’s the polar opposite. Although EA might highlight areas where overnight and radical change could benefit a business, the initiative itself is a constant and gradual effort in working to align business and IT, aid in strategic planning, and improve processes.

As time goes on, the degree to which these efforts can positively affect the business will also increase, as the EA practice becomes more mature. The added capabilities of EA are indicated in Gartner’s maturity model shown below.

Teething Problems in Enterprise Architecture: EA Maturity Model

This is important for two reasons. Firstly, a maturing Enterprise Architecture practice implies business growth, and so more EA has to be done in order to cope, as there is  more to manage.

Secondly, maturing in EA enables businesses to do a different kind of Enterprise Architecture. The typical, Foundational EA tasks – the one’s we refer to as keeping the lights on – will still be carried out. However, a more mature Enterprise Architecture practice can start using EA more aggressively, actioning what is known as Vanguard Enterprise Architecture Enterprise Architecture.

This kind of EA is more proactive, and it’s practitioners focus more on identifying opportunities and disruptions. This is the EA largely responsible for pushing business transformation and innovation, and so their results often have more lucrative, tangible results.

Most practices that abandon EA, do so without moving too far along the maturity model and so in most cases, are only doing entry level, Foundational Enterprise Architecture.

Problems in Enterprise Architecture: EA Needs Attention

Much of EA consists of strategic planning. Thanks to the practice’s macrocosmic (top down) view of the organization, and business wide responsibility, the planning carried out by EA’s can affect the business as a whole. When dealing with change of this nature, what is implemented cannot be started and left to integrate on its own. This sort of radical change needs to be guided and supervised.

This is why if a business is going to take on EA, they need to think about the EAs wider role in the organization. Who should they report to, who should report to them etc.

Many people make the case that EAs should report directly to the CIO, and in fact, hold an advisory role to the CIO as well. Gartner analyst, Brian Burke echoes this sentiment, stating: “We’ve witnessed a change in mind-set, execution and delivery of EA. The value of EA is not in simply ‘doing EA’, but rather in how it can help evolve the business and enable senior executives to respond to business threats and opportunities.”

Therefore, just implementing the scheme isn’t enough. It needs aftercare. This is why EAs should work closely with CIOs, and the benefits of this come two-fold. On one side, the CIO gains a valuable asset in having an adviser with perhaps the most broad, top down view of the organization and its structure, in the business. On the other, the Enterprise Architect has a role more closely aligned with the top table, and can exercise more pull in decision making.

This relationship, and the extra attention to EA it provides could be the difference between success in EA, and an amassment of half started projects and eventual lapse in investment.

Enterprise Architecture & Data Modeling White Paper

Categories
erwin Expert Blog

Enterprise Architecture’s Economic Value

In the past, the economic value of enterprise architecture has been hard to show.

Yearly surveys routinely indicate a need for enterprise architecture (EA). CIOs often list implementing or improving an EA initiative as a top priority. Despite their position at the “top table”, CIOs are still expected to justify their plans to invest in EA (or elsewhere), based on the plan’s expected effectiveness.

In theory, the benefits of enterprise architecture should justify themselves. But the niche and expert nature of the practice means the value doesn’t always translate well to those outside of the immediate stakeholder community.

In this case, CIOs, Chief Architects, EAs and the like, need to show the economic value of enterprise architecture. But how?

The Economic Value of Enterprise Architecture

The Economic Value of Enterprise Architecture

The need for enterprise architecture can be summed up by two of its main goals – aligning the business and its operations with IT, and bridging the gap between the organization’s current state, and its desired future state.

The economic value of enterprise architecture often comes as a result of nearing the ideal state of these two goals. I say nearing, as Enterprise Architecture initiatives rarely achieve perfect alignment. The two goals work against each other in this regard – success in bridging the current/future gap, creates a constantly changing landscape, and business/IT alignment has to be adjusted accordingly.

With this in mind, it could be said that the economic value of enterprise architecture is achieved in the long term, as opposed to the shorter term. That said, there are a number of markers of success that can be achieved along the way – each providing clear and tangible benefits to the organization that undoubtedly hold economic value of their own merit.

There are a number of indicators of success within EA that indicate the initiative’s economic value. Four core indicators come in the form of improving strategic planning, communication and risk evaluation, and tactical advancements. These markers can be seen as best practices in order to work towards, to fufil the overall goal of making an EA initiative an economic success.

Improving Strategic Planning

Enterprise architecture is often seen as the bridge between defining a strategy and its implementation – hence one of EAs main goals being to bridge the gap between the business’ current state, and its future.

EA adds a much needed dimension of transparency to strategy implementation. It’s often the guiding rope for implementing strategy that will affect the whole business. Because different business departments often work in silos that aren’t all completely in sync, new initiatives can suffer from a lack of foresight and lead to disparity and disconnections in data and ideas.

Enterprise architecture works as a framework to ensure no department/silo is overlooked, and that with the new strategy, each separate business arm is still working towards the same goal.

Bettering Communication

Enterprise architecture is arguably concerned with strategic planning, first and foremost. But there will always come a time when that strategy has to be communicated to the wider business for it to be successfully implemented.

The problem most businesses will find here, is that due to the holistic, top down, and all encompassing perspective EA has on the business, and the universal/inter-departmental changes any strategy EAs suggest can cause.

This is where the right enterprise architecture tool is important. Rather than just the actioning of enterprise architecture itself.

The right enterprise architecture tool can enable the various stakeholders relevant to a proposed scheme, to actually collaborate on the project to ensure the strategy works in the best interest of all parties.

In the past, enterprise architecture has been deemed as an “ivory tower” profession, catering only to the expert. This is still true to some extent, especially when talking about back end data and the repository. However, that doesn’t mean the results at the front end aren’t useful to non Enterprise Architects.

The right tool can enable true collaboration (in tool, not just reports and feedback which can slow down the process) and therefore be a great asset to line managers, C-Level executives and others as they can be a more critical part of the planning process.

All in all, this facilitating of true collaboration should improve the communication and coordination of strategy implementation, and lead to less false starts, wrong turns and a return on investment that’s both faster and more fruitful.

Tactical Improvements

As well as improving the strategic planning process, enterprise architecture plays a huge role in improving processes overall. By taking a look into what is aligned, and what isn’t, EAs can uncover areas of redundancies – where two separate processes are being actioned when they could be merged into one.

There are many examples of this across varying sectors, especially when an organization has been void of EA until now, or is on the lower end of EA maturity. These businesses tend to be less aligned and so suffer from the issues typical to such situations. These issues can range from a non standardized practice for keeping and labeling data, leading to duplication and corruption, to different departments holding separate licenses for software that does essentially the same thing.

By identifying these discrepancies, enterprise architects can save an organization both time and money. Both of which hold clear economic value.

Taking Better Risks

Modern enterprise architecture is often seen as a two headed coin. One side, the Foundational side, deals with the ‘legacy’ IT-based tasks – what we refer to as keeping the lights on, keeping costs down etc. The tactical value of enterprise architecture resonates most vibrantly here.

Vanguard enterprise architecture is the other side of this coin. This more modern take on enterprise architecture was introduced to reflect ITs shift from a solely support based domain, to a role more central to the business.

Vanguard EAs are the forward thinkers, more concerned with innovating, and bridging current and future gaps in technology, than the alignment in the present. In this regard, enterprise architecture becomes a fantastic tool for evaluating risk.

Although evaluating risk can never be seen as an exact science, vanguard EAs are invaluable in that they can help indicate what strategies should, or should not be pursued based on their potential value to the business, and the costs it could take to implement them.

The Business Capability Model, for example, can indicate what a business is already suited to achieve. Therefore, they can be used to point out strategies the business might be able to implement more readily.

Categories
erwin Expert Blog Enterprise Architecture

5 Things You Should Know About Big Data Enterprise Architecture

Big Data has changed the way in which organizations understand and make use of the growing volume, velocity, variety and value of enterprise data. Any company, whether large or small, can take steps to analyze and make use of the disparate information it has access to, speeding up and increasing focus on initiatives that help drive and grow the company.

With the correct approach, enterprise architecture helps the business target the right market activities and fine tune marketing, sales and business operations. In fact, almost any business transformation initiative can be addressed by utilizing Big Data techniques. Techniques that can help enterprise architects ensure alignment with the business and maximize return on investment.

Architects typically already know the business capabilities they need to deliver and have a roadmap outlining the applications, technology, people, processes and resources needed to accomplish it. Big Data is different in that it enables architects to follow ideas where the outcome isn’t clear, and the data is often wont to trigger new questions or ideas.

A more agile approach to architecture development is required to handle this than what many organizations have in place today, to allow the organization to react and respond where needed to capitalize on opportunities when they arise.

With that in mind, here’s 5 key things you should know about Big Data Enterprise Architecture.

Big Data Enterprise Architecture in Digital Transformation and Business Outcomes

Digital Transformation is about businesses embracing today’s culture and process change oriented around the use of technology, whilst remaining focused on customer demands, gaining competitive advantage and growing revenues and profits.

By focusing on desired business outcomes, companies can target specific initiatives that are likely to yield high returns or deliver greatest business value based on digital adoption. Big Data may be incorporated into business strategies to help drive meaningful strategic adjustments that minimize costs and maximize results.

As more businesses become digitized, the amount and complexity of enterprise data grows, and so making use of it to better understand your customers, employees, operations, and how your products and services are performing has never been more challenging or essential. Some ability to understand and analyze Big Data can help identify the opportunities to reduce costs, serve customers better, or eliminate risks across the architecture of the enterprise.

In fact, it could be said that without any element of Big Data analysis, it’s hard to do digital transformation at all.

Enterprise Architecture Makes Big Data Easier to Digest

CRM and ERP tools are a hive of useful data. Enterprise Architects can use this data to highlight areas of opportunity and potential disruption.

Alongside this, the rise of social media has uncovered a new data goldmine, and online tools like Google Analytics provide deep insight into the consumer. Of course, this is implied by the term “Big Data”.

That said, businesses won’t find all of the data useful at any given time. The organization’s current goals and objectives should influence which parts of the data to hone in on in order to make things more manageable.

An Enterprise Architecture tool supporting a view manager can help achieve this. Organizing the same data into different views in an instant can make finding the best data thread to pull, much easier. Essentially, a view manager streamlines data into customizable, and easily digestable representations that can be updated in real-time. This allows Enterprise Architects to make comparisons far more readily.

A best practice in this instance, is to use EA to sift through Big Data, and find one metric that holds a clear influence on reaching your desired outcome. From here, EAs can branch out and find other useful data sets that can be applied to ensure decisions are as well informed as possible.

This can help eliminate guesswork and save time and cost by avoiding trial and error Big Data work.

Big Data Isn’t Just for Big Business

It can be an easy assumption to make that Big Data is best left for Business Analysts, and the typically lager organizations where they’re employed. However, in the current business landscape, its possible for any business to drill down into Big Data by leveraging the various tools available on the market.

These tools can help find, structure and manipulate data, as well as present them to the wider organization in order to influence strategy.

In EA specifically, the tools available can help you gain a deep understanding of your current-state and past-state enterprise data activity, and therefore can be used to help understand trends and make projections that influence your future-state enterprise.

Reports of this nature go along way, for example, by indicating whether a specific Digital Transformation workstream is worth pursuing or not, as well as steering it once the target future-state has been agreed upon.

Big Data Can Help Position EAs in an Advisory Role

A key objective of Big Data is to surface new value from extensive data sets, and as an Enterprise Architect you should be prepared to advise your business and IT stakeholders on how its possible to leverage Big Data techniques to achieve their objectives.

We’ve talked before about how EAs could in fact, be best place to be a front line in advising the CIO, due to their holistic view of the organizations assets and potential.

To properly leverage Big Data to position yourself at the ‘big table’, EAs should recognize that every enterprise is unique with its own goals – the drivers for each company differ, and near-term and long-term goals can and do change over time.

By understanding the business goals, key challenges and business outcomes, Enterprise Architects can start to break Big Data down into insights that will drive success.

The use of SMART (specific, measurable, achievable, realistic, time) based goals can allow you to have concrete criteria upon which to measure results and effectiveness.

Big Data EA and the Business Motivation Model

The business motivation model (BMM) in ArchiMate® can be used to describe the goals, drivers, assessments carried out, and stakeholders involved in decision making. It’s a way of putting factors of influence on the business in context, providing a language in which they can be discussed and used to better strategic planning.

An invaluable tool for Enterprise Architects and the wider business, the motivation model helps improve decision making by adding a structure and cohesion to the strategic planning process.

Most EAs agree that there is still work to be done in order to reach a perfect (or even near perfect) alignment between IT and the wider organization – something that CIOs across organizations are striving for. Much of the reason for this shortcoming, is a lack of effective communication.

The cohesion in planning achieved by a business motivation model, makes it far easier for plans to be communicated across departments and ensure everybody is working towards similar outcomes. This mutual approach is the driver behind this business and IT alignment.

The connection between the BMM, and Big Data Enterprise Architecture is simple. In short, Big Data provides additional and much needed context to build better informed BMMs. The more data you have surrounding a specific influencing factor, the more accurately you can predict the extent of said influencers, influence. Enterprise Architecture can help refine Big Data for this purpose, so analysts and other relevant parties can see a snapshot of only the relevant data, essentially cutting the fat.

Categories
erwin Expert Blog

Justifying Enterprise Architecture Investment

The increased frequency in organizational disruption – thanks to the rise of the Internet of Things (IoT) and increased focus on digital business – has made Enterprise Architecture (EA) more integral to business than ever before.

EA is needed in order to steer through such disruption to not only limit any negative fallout, but to best capitalize on the disruption, and exploit opportunity, too.

Still, acquiring the necessary funding to invest in EA in order to mature the practice can often be difficult, with reports indicating 50% of clients sourcing a new EA tool are unsuccessful in gaining approval on the first attempt.

This is surprising considering how EA benefits the organization, and the importance placed on these benefits by business leaders. Benefits such as:

  • Faster time to markets
  • Increased agility, efficiency and effectiveness
  • Uptick in innovations in the organization’s structure
  • Better alignment of business and IT
  • Reduced costs in implementing innovations
  • Reduced risk

The Enterprise Architecture domain hasn’t helped itself in this regard. The expert nature of its function is fundamentally exclusive, rather than inclusive, and historically, EA tools have reflected this.

Pitching the right tool

Enterprise Architecture’s ivory tower perception has made pitching tools difficult, as it’s hard to convince a stakeholder/business leader/decision maker of the tool’s value if they don’t fully understand how the tool is applied.

Oftentimes, the best way to pitch an idea, is to demonstrate to the person how they would be involved in its implementation. Therefore, an EA tool should be both capable of carrying out the needs of the specialists, whilst still being open enough for stakeholders to be properly involved in both the decision to buy and the use of the tool going forward.

Traditionally, this hasn’t been possible as the learning curve for EA tools alienated non experts. Even people in the industry often found the user interfaces to be unwelcoming and difficult to navigate. However, as the world has become more digitally orientated, and UI design has improved, the desire to have an EA tool that works for Architects and the relevant stakeholders can now be realized.

Corso Agile Enterprise Architecture

There are tools capable of the same high end functionality as EA’s have come to expect, as well as being user friendly enough to enable collaboration between experts and non-experts alike.

If the tool you’re evaluating has a trial period, collaborating with said stakeholders and fellow team members right off the bat is a great way to demonstrate its potential.

Pitching the tool right

The business outcome approach to EA typically assumes a business is already doing some sort of recognized EA. However, the same ideas can be applied to the pitch.

Take ‘Just Enough‘ for example. A business outcome orientated take on Enterprise Architecture where EAs aim to do ‘just enough’ EA and avoid analysis paralysis, slowing down workflows and time to markets.

When pitching the need for EA investment, Enterprise Architects could apply this principle by showing, ‘Just Enough’. Meaning, instead of spending time talking about the tool’s back end data and repository to a stakeholder that won’t be involved in it, focus on showing the results the repository will be used for.

Stakeholders want to see how an Enterprise Architecture initiative will bring the organization closer to it’s desired business outcomes, but they’re not too worried about the specifications that will have it happen.

Focus on the cost savings; on the reduced time to markets; on the increased agility in the face of change and disruption, to name a few.

The idea behind this approach is that, if we can demonstrate the value the tool will bring to the business, how it brings that value will be less important.

Leverage Established Examples

By using already established examples of EA’s merit as a proof of concept, Architects can add credibility to the pitch, by showing the real world application and the results produced.

Although every organization’s Enterprise Architecture will be unique to them, demonstrating what an EA investment has done for others is still a viable tactic.

It’s likely that many businesses will desire similar outcomes, even if the environments in which those outcomes will be planned for and achieved are different.

Examples of Enterprise Architecture in practice and how it has helped/is helping the Enterprise Architect(s) in question can be found here and here.

Categories
erwin Expert Blog

What Makes an Enterprise Architect?

The current push towards digital business and adoption in IoT has caused a revitalized demand of the Enterprise Architecture (EA) profession.

EA was often seen as a business arm of IT dedicated to support or “keeping the lights on”. However, a changing business landscape has meant architects are now expected to innovate, meet and navigate disruptions, and liaise with business leaders and decision makers.

Considering this evolved role, and the increasing demand for the profession, it’s worth taking a look at some of the most essential skills Enterprise Architects need to demonstrate.

An IT and Business Minded Approach

Speaking on the importance of Enterprise Architecture in modern organizations, and the domain having a business focus, Network World Editor, John Dix said: “The enterprise architect role today is becoming more critical because virtually every business project has a core IT component and companies need players involved that have a big picture view.”

“Organizations are constantly struggling with change and the enterprise architect role helps to ensure projects are mapped out with realistic goals and the infrastructure is there to support those goals now and in the future.”

One of the biggest changes to IT over the recent years has been its place within business. As IT in general has become absolutely essential to how most businesses operate, it now has to operate with a far more pronounced business emphasis.

A recent IDG and Network World led study indicates this is most certainly true for EAs. In it, 88% of all IT Architects (Enterprise, Solution, Infrastructure etc included) said they needed to communicate with both IT and business in mind, making sure their reports translated to those outside of IT, as well as in it.

The same percentage also expressed that mapping capabilities to business needs was a priority.

Leading tech analyst, Gartner have noticed a similar trend. In recent years, Gartner have stressed the importance of doing “Business Outcome driven EA,” and arguably, this new tack has been one of the factors helping the profession grow.

This is one of the main reasons Enterprise Architecture needs to shake its “ivory tower perception.” EA’s place in the business is far too centralized to be unapproachable by non-experts, and so Enterprise Architects who can successfully accommodate both fellow architects and stakeholders are invaluable.

Many EAs are already halfway there. They understand the importance of working alongside decision makers and stakeholders, but in some cases, just don’t have the right tools. In order to truly encourage business leaders to get involved in the EA, an agile, collaborative tool is a must – more on the importance of dedicated EA tools here.

Leadership and Influence

The Enterprise Architect’s top-down helicopter view of the business means they tend to have a great understanding of the enterprise, it’s current capabilities, and its requirements going forward. Although these are great perspectives to have in and of themselves, like most advantages, without proper application they can be wasted.

Leadership is the key to making the most out of this big-picture perspective.

Without leadership, fulfilling core EA duties such as steering through disruption and driving change can’t be done effectively.

Additionally, Enterprise Architects tend to be aligned more closely with IT Management and CIOs than other IT professionals. The same IDG study cited earlier found that 85% of EAs originated ideas that have directly impacted the business model and go-to-market strategy.

This is because their top down insight is extremely valuable to business leaders. EAs must learn how to hold the floor with such business leaders in order to effectively provide their recommendations. After all, that’s what they’ve been employed to do!

Forward Thinking and Agility

It’s vital that Enterprise Architects keep an eye on the future. They have to be prepared to face disruption and new opportunities, but also, they are often responsible for making the case for disruptive technologies.

They need to be aware of the current market, as well as how the market is likely to change to live up to this responsibility of identifying and proposing innovative solutions to help the business achieve its goals.

In sourcing new technologies, EAs must be diligent in their vetting. They’re the bridge between the technology and the upcoming project(s) in mind and have to ensure the pieces fit into the wider business outlook.

This forward thinking is a big part of Enterprise Architects effectiveness in helping the business be agile. However, Enterprise Architects must also employ a number of other best practices in order to stay agile. Most important of those perhaps, is a dedicated Enterprise Architecture tool that permits such an approach. But focusing on the actual EAs themselves, sticking to mantras like “Just in Time” and “Just Enough” Enterprise Architecture can aid in speeding up the time it takes for the business to respond to change, make more informed decisions, and reduce time-to-market of new products and services.

Enterprise Architecture & Data Modeling White Paper

Categories
erwin Expert Blog

How To Kickstart an Enterprise Architecture Initiative

The increased rate in technology disruptions means more businesses than ever will be looking to start up an Enterprise Architecture (EA) initiative. This has extended to smaller businesses too – many of which wouldn’t have considered EA before – due to the availability of more accessible tools.

But where to start? Previously, looks into Enterprise Architecture tooling uncovered two alternatives. The legacy, established EA tools, high in productivity but equally high in cost and effort, and the drawing tools – such as Visio – that require excessive management and juggling of information between multiple applications.

start enterprise architecture initiative

First Steps in Enterprise Architecture

It’s important to establish what Enterprise Architecture is for, and why you would need to get started. Superficially, Enterprise Architecture is about the description and management of systems. In the past, it had been typified as a domain fit for “keeping the lights on” – the legacy attributes associated with IT. Today, largely due to the rise in digital business, the role of an Enterprise Architect has been pulled out of the shadows.

Now, Enterprise Architecture is more concerned with responding to disruption. EAs identify the potential for business and IT change, and analyze how best to execute or manage such changes to meet business objectives, desired outcomes and vision.

The Beginnings of Enterprise Architecture Maturity

Chances are, if you’re just starting out in EA, you’ll be ‘pre level 1’ on the maturity model. To take that first step into maturing the practice, and before you really start working on what your future state architecture looks like, you must understand your current state.

The frameworks to which your Enterprise Architecture will observe are also decided here. TOGAF, Zachman, DODAF are three common examples of such frameworks.

Your choice will ultimately come down to what you’re trying to achieve with EA, the experience of your team, and whether you prefer a defined model.

To reach full maturity, your EA initiative will have to transition from ad-hoc, reactive EA, to something repeatable, and so a defined model best suits this long term aim. Typically speaking, the TOGAF method is most widely adopted.

Enterprise Architecture Maturity

That said, some organizations won’t want a standard method, and may start with a few object types and relationships.  What matters most is that its understandable by the organization and that its repeatable.

At this point, you can move onto ‘Level 1’ maturity, carrying out ‘horizontal assessments’ of the business.

This is essentially ‘cleaning up’, sorting the data, resources etc., involved in the architecture of the enterprise, in order to build upon strong foundations going forward.

Any existing architectures should be united under one model, and one standard of terminology.

Disparity in this area can cause problems down the line, as it’s often common for different departments to have different names for the same thing and vice-versa, leading to duplicated or inaccurate data.

This is the point whereby existing data is imported into the EA repository. This should identify what the business has, and allow for modeling, roadmapping etc. going forward.

A best practice at this stage, is to start by creating a metamodel. Metamodels provide the top down, abstract view of the business and help EA’s establish alignment.

For example, they show the relationships between applications, and the business process they support, and a lack of such relationships and connections indicates areas of the architecture that aren’t properly aligned and non-functioning.

What Do I Need to Start An Enterprise Architecture Practice?

Most businesses start small, and mature the practice as they go, but some businesses with deeper resources opt to buy their way through Enterprise Architecture maturity – hiring consultants and acquiring a heavy-weight EA tool right off the bat.

For businesses where this isn’t an option, the usual process is as follows…

Typically, lower maturity EA set-ups feature a small team, an ad-hoc approach, and free and repurposed tools.

But as these EA practices grow, architects, stakeholders and business leaders often find that this approach can quite quickly become difficult to maintain.

Managing something as complex as an Enterprise’s applications, technology, information and processes across a suite of different tools that don’t interact with each other is hard enough as it is.

Then, when you factor in a growing team size, and add collaboration into the mix, this method can become nigh on impossible to sustain. sooner or later, an EA tool is required.

For more on deciding the best time to acquire a tool, click here.

How Much Do Enterprise Architecture Tools Cost?

Many companies think they can’t justify the costs, lengthy implementations projects and other resourcing factors. However, with the emergence of the Cloud and Software as a Service (SaaS) model, much of these initial headaches can be avoided. SaaS pricing models usually work on a “pay for what you need” basis, reducing the threat of a new tool purchase becoming shelfware. This makes them a great option for businesses who are looking to introduce an Enterprise Architecture programme for a specific initiative.

The SaaS model is also great for businesses that are looking to get off the ground quickly. The burden of having to pay for a consultant or technician to install the tool locally is relieved – saving both time and money.

We’ve seen a shift towards the model from leading tech providers recently. More and more enterprise tools are moving to the Cloud. One prime example is Google and their Apps for Work. Not only does the model save time and money, it can also greatly improve collaboration. Google’s suite demonstrates this, by allowing users to work together on a document or project remotely. Considering the nature of Enterprise Architecture – it’s top down view of the organization, and its inter-departmental linking of systems, people and other resources – this enabling of collaboration is vastly important to the industry.

Start enterprise architecture - Free Enterprise Architecture & Data Modeling White Paper

Categories
erwin Expert Blog Enterprise Architecture

How Agile Enterprise Architecture is Helping to Build Smart Cities

Having an agile enterprise architecture is essential to enabling a smart city.

One of the challenges when creating a smart city is how to represent all the moving parts. From my perspective as KnowNowCities designs new smart places the best approach is to use agile enterprise architecture techniques to describe how the technology is applied in a place.

What is a Smart City

Firstly though, let’s start by explaining what a smart city is. The elements of a smart city can be boiled down into 5 interwoven and parallel components.

These are:

  1. Apply standards – such as Privacy by Design and PAS181 – Smart City Framework
  2. Are Open Data Centric – see the Open Data Institute
  3. Are Interoperable – so data and services from one place can interact with another place
  4. Have good governance and leadership (both hard and soft)
  5. Are Outcomes Centric and put Citizens first. Citizens make cities what they are

In short these become the overriding Smart City principles. So a key role of any enterprise architecture is to demonstrate how the technology designed meets these principles.

agile enterprise architecture smart city

Smart City Enterprise Architecture

The role of an EA in a smart city is multiple. Typically when building a new place the overriding concern is maintaining the promised return on investment. The developer needs a place that will attract customers (good rental or freehold returns); be compelling and competitive so the new place has its own ‘unique selling points’; yet, not break the bank! The EA can aid the developer in what I term is a “plan for tomorrow, but build for today” approach.

What does this mean? Planning for tomorrow is about making sure where it is going to be expensive to retrofit in the future mitigate that expense by deploying sufficient capacity for the future where it makes sense.

Simply put, this is about the reservation and allocation of space and capacity where technology may well end up being deployed. But not necessarily deploying that technology.

An example would be deploying conduit underground during the civil engineering phase of a build, but not deploying the cable through the conduit. Provide the access rights and access points to deploy any technology upgrades (be it for technology refresh or for capacity gains).

Another key aspect when designing a smart city is to recognize that technology is now part of the urban design. Yet traditional architecture of buildings and the public realm does not easily address the adoption of technology. The key here is to be embedded in the architecture and construction team from day one. As I tell my clients… technology engineers for a smart city should be considered similarly to the water engineers.

With Water you have three types (blue – potable, grey – rain/surface run off & black – waste) that each require their own special attention. When you think water… now also think technology!

Integrate with the RIBA Plan of Work

Luckily from a technology perspective having a plan of work that goes through distinct phases also fits nicely with an Enterprise Architecture centric method too. The RIBA Plan of Work method can be applied to the technology aspects of a smart city as much as it can the construction of the buildings and public realm too. So at concept stage, the technology concept architecture can sit in that phase too.

Roadmaps are the icing on the cake however. Referring back to the principle of design for tomorrow but deliver for today. It is possible to show when a particular technology component is required, how it flows from previous technology deployed/enabled and how this then supports future technology growth/deployments.

Additionally, because the EA at a concept level is exactly that, a certain amount of stability can be expected. Let us not forget that technology has a lifespan often measured in months, whereas a structure’s lifespan is measured in decades. So the EA becomes a living organic entity. Constantly evolving and changing based on need and technological capability.

Yet it is the specified and physical designs that are likely to change here. Again, the EA approach allows for this transfer of different types of technology, yet still keeping a cohesive overall architecture that can still represent the principles and concept architecture the first design delivered.

How Does erwin Evolve help?

The beauty of using erwin Evolve is that the tool provides all the outputs that are required in a smart city engagement.

Firstly, it is great way of capturing the requirements and then matching those to principles, owners and then attributing this to architected components.

Secondly, the tool can manage capacity plans, and what if scenario planning.

Thirdly, using the roadmaps and Kanban views the tool can help a client prioritize and plan the work to be undertaken.

Finally, because of erwin Evolve’s collaborative features I get to share a common view with all project stakeholders.

enterprise architecture business process

Categories
erwin Expert Blog Enterprise Architecture

Just Enough Enterprise Architecture, Just In Time: 5 Best Practices to Achieve Peak Enterprise Architecture Agility

The concept of ‘agility’ has permeated almost every inch of the enterprise. It’s not hard to see why either. The promise of faster time to markets, better management of change and disruption, and leaner, more efficient operations is clearly an appealing.

Enterprise Architecture (EA) is no exception to the rule. It might have been, for a time – when EA only really concerned itself with ‘keeping the lights on’. But now that the domain has found itself aligned more closely to the center of the business EA has to be concerned with agility too.

Some Enterprise Architecture practices can struggle to really achieve agility because of various reasons. We’ve put together 5 best practices to help architecture teams deliver greater business agility and also become more agile in their own approach to EA.

Just Enough Enterprise Architecture, Just in Time

One of the most common barriers to agililty is doing too much. The complex nature of Enterprise Architecture can lead to some architects building many rabbit holes where too much unnecessary information is captured and modeled that work is never ‘done’. This state is known as ‘analysis paralysis,’ as it effectively slows down the process and time to market of EA business-outcomes. Architects should stay focused on delivering Just Enough EA to support business outcomes, instead of documenting every last detail of the organization.

Of course there are times when very deep EA is required, but as a general rule it is better to focus on Just Enough Enterprise Architecture. Whether through curiosity to learn more, or paranoia that something will be missed, attempting to model and analyze everything is fundamentally at odds with agility.

To help focus on Just Enough EA and avoid getting lost in the detail, architects should:

  • Separate Enterprise Architecture from Solution Architecture, understand that detail does exist where Architecture meets design
  • Use a goal based decision process, keeps a focus on what needs to be built and by when
  • Concentrate upon interfaces / relationships
  • Define the core properties to be collected and implement quality checks
  • Harvest and connect to records of source

A lean and agile approach to Enterprise Architecture allows architects and non-architects alike to access the information they need much faster too, since EA modeling and content is no longer weighed down by a lot of unneccessary detail. EA is more likely to secure investment this way, too – as stakeholders are more likely to invest when the business outcomes can be translated more clearly and quickly.

Engage and Collaborate with Business Stakeholders

Another hurdle to EA agility is approval. Architects often reach a point where they can’t continue without the approval and buy-in from business leaders. The quicker you can get your stakeholders on board, the faster you can move through the strategic planning process into execution. This efficiency is essential to the agile mantra.

The ivory tower perception of Enterprise Architecture that has traditionally plagued the discipline makes this even more of an issue. Stakeholders are more likely to be reluctant to invest (be it time, money or resources), if the business outcomes aren’t completely clear.

One way to solve this is to help stakeholders get a better understanding and view of enterprise architecture. Getting them engaged and collaborating on the applications, processes or business capabilities they are interest in via an easy-to-use EA tool is ideal. We can also borrow ideas from Just Enough Enterprise Architecture (mentioned above). Your stakeholders shouldn’t have to learn how to do Enterprise Architecture in order to provide input and see its benefits.

Organizations with a collaboratively driven tool can provide stakeholders direct links to specific assets in the architecture. This negates any learning curve stakeholders might have needed to navigate the tool itself, gets them straight to their point of interest, and saves them time.

Enterprise Architecture collaboration

Giving stakeholders the ability to view and contribute directly within the EA tool itself, negates the need to go back and forth with static diagrams and reports. Instead of printing out PDFs and the like (which is actually just sharing), EAs can collaborate with stakeholders in realtime allowing them to see the impact of different changes on the business and to guide investment decisions.

Ensure Your Content is Stakeholder Focused

Although it’s best to engage and collaborate with stakeholders in EA, in some cases, the stakeholders can only really take a passive role. In this case, making sure what you present to the stakeholder is tailored to them, is another great way of removing stakeholder concerns as a hurdle to agility.

View managers are a great quality of life data management system, that can help EAs achieve this. They’re already commonplace in many Business Intelligence tools and CRM Systems, but can be just as useful in EA.

The purpose of a view manager is to streamline both the visulaization and navigation of data. They take a set of user defined parameters, and act as a filter to show only what’s relevant to that view.

View Manager explained

Much of this ties into the concept of showing ‘just enough’ EA and can help users and the wider business stay agile by trimming the irrelevant data that can slow down decision making.

View Managers could also be used as a tool specifically purposed to improve agility and efficiency across the business. For example, a view could be created to always display all business capabilities or perhaps all applications that you own. It could then be sorted to show the most critical capabilities – based on their importance to the business – first.

This helps provide architects with a clear view of their own priorities but similarly which organizational priorities should be tackled first.

A business capabiltiy view is just one possible example. In terms of agility, the view would help improve the efficieny at every stage in strategics planning process, increasing agility and time to market across the board by improving systems and processes.

Kanbans

Kanban Boards are a common form of task management in business. In short, they operate as a visual representation of the current state of a specific task(s). The typical parameters are “to do”, “doing”, “done” and “parked”, but many businesses choose to define their own parameters to better suit their needs. For example, a Kanban board that follows the different stages of the TOGAF ADM.

In relation to agility, Kanbans are a great way of organizing and prioritizing your own and your teams activities. This structure is the basis for any credible attempt at a truly agile operation. Without it, organizations often find themselves wasting more time deciding what should be done, that actually doing.

Kanban’s are versatile enough to be used at almost any point in the strategic planning process – including Enterprise Architecture. In EA specifically, Kanban boards could include cards representing business capabilities, or application components, providing a work in progress view of the architecture.

Get the Right Tool

Most organizations start small with EA, repurposing tools such as Powerpoint, Excel and Visio.

This budget approach to managing EA can most definitely get you off the ground. But as the architecture grows, the silos created when fragmenting the architecture across multiple programs and file types stifle progression.

It becomes difficult to work collaboratively, as multiple team members struggle to keep aligned. In many cases, there will be multiple different versions of the architecture that don’t fully corroborate with one another.

The most direct impact on agility though, is the fragmented state of information and assets. The dispersed nature of the data makes it extremely hard to find the information you need, making the EAs day-to-day job harder, as well as introducing further complications when presenting the architecture to stakeholders. EA can be complicated enough for the experts, let alone the stakeholders that are only involved sporadically. These are complications it can do without.

The right tool would be one that unifies the Enterprise Architecture, as well as the architects – allowing them to work collaboratively within one tool, with real time feedback and comment systems across the diagrams, roadmaps, pivot tables, impact analysis and capability models.

collaborative enterprise architecture

Categories
erwin Expert Blog Enterprise Architecture

Collaborative Enterprise Architecture Needs More Than Sharing PDFs

Collaborative enterprise architecture isn’t a new idea.

The very nature of Enterprise Architecture (EA) demands a collaborative effort. Enterprise architects are responsible for the architecture across the company, but they don’t own it. That’s down to the relevant departmental managers.

This considered, EA has long claimed to be a collaboration focused – but how collaborative is it?

Thanks to advancements in tech, the wider standard for collaboration allows even global organizations to share work, edit and comment. Because it’s all happening in-tool, it’s all logged and changes can even be represented in real time. Google’s Apps for Work has taken the enterprise by storm, and is a great example of this.

However, in the majority of cases, Enterprise Architects “collaborate” through reporting. But reporting being an avenue of collaboration shows a fundamental misunderstanding. Reporting is one-way, a dictation of what has already been done. Collaboration indicates that what has been done, has been done cooperatively. This means live input, suggestions and even changes by the relevant parties during the process.

Furthermore, not only is simply sending out reports not collaboration, the process is fundamentally flawed.

  • Changes have to be given after the fact, causing delays and other knock on effects
  • In many cases it might even be too late to make significant changes
  • Data outside of the tool is essentially ‘passive’ only, limiting its usefulness

The truly collaborative Enterprise Architecture approach

Compare this to truly collaborative EA. Feedback is given as the EA initiative develops, largely eliminating issues with delays. But with the complex and organization spanning nature of EA considered, facilitating collaboration the traditional way – through sharing office space and discussing things face-to-face – is infeasible  To be truly collaborative, Enterprise Architecture must facilitate collaboration ‘in-tool.’

Take Google’s Apps for Work suite. The mega corporation has long been a driver of technology, and an aspirational standard for software developers. Apps like Docs, Sheets and Slides have revolutionized the workplace, allowing collaboration in real time both in the office, and between different office locations.

Considering what’s expected of Enterprise Architecture and its Architects, it doesn’t take much to connect the dots. This is where Enterprise Architecture needs to be.

The benefits of truly collaborative Enterprise Architecture

Agility

Getting greater engagement and collaboration in EA from all relevant business and IT stakeholders, helps keep EA model content up-to-date. This supports faster and more reliable decision making.

Leading analysts have been expressing the importance of Agile EA for some time now, and the message hasn’t changed. Still, report-based collaboration as it’s widely executed in EA, is a barrier to such agility. In most cases it requires exporting data outside of the tool, where it can only be useful ‘passively’. It can’t be manipulated or re-worked.

This ‘half-baked’ take on collaborating essentially guarantees duplication in process. Either having to ‘regress’ and make changes after the fact, or in some cases, particularly in larger teams of architects, rework models, roadmaps and the like from the ground up, to ensure they’re aligned across the platform.

A truly collaborative approach, supported in-tool negates this, as everybody is updated in real time, and the architecture including changes to it can be commented on directly. This is also hugely beneficial going forward, as this sort of collaboration, encouraging people to comment in tool, essentially logs the thought process and reasoning behind certain changes and actions, allowing the EA department to be reviewed far more efficiently.

Enterprise Architecture Collaboration

Encouraging stakeholder buy-in

Stakeholders, decision makers, management. Traditionally, they’ve always been difficult for Enterprise Architects to get on board. The ivory tower nature of Enterprise Architecture can be a barrier for the non-expert and they may not fully realize the value.

However, with the acceleration in digital business, organizations can no longer afford to do this. Enterprise Architecture is essential for steering this acceleration, but it still needs to be more encompassing for senior figures to make the leap of faith.

True collaboration around EA helps in a number of ways. Consider the points below:

  • Trying to sync up busy calendars for meetings and the like is no longer an issue – the Enterprise Architecture can be shared with the relevant parties directly
  • It’s far easier to encourage additional investment to mature the Enterprise Architecture –  if those in charge of budget are directly involved in the Architecture, rather than passively, they’ll be easier to convince

This is a relatively new advantage to true, and in-tool collaboration, as in the past, inviting decision makers into the tool during the evaluation process required them learning how to navigate the complexities of the EA tool, or else sharing a PDF or Powerpoint presentation. However, modern EA can avoid this headache, with SaaS, web-based EA being as easy to navigate as clicking through a URL.

Decision makers can be sent directly to a point in the tool – to a diagram, roadmap, pivot table etc – via URL and submit their feedback, suggestions and/or concerns. The ideas behind leading collaborative apps are at play again here. Think ‘sharing’ in Google Drive, Docs, Sheets etc. In this case, proving the value of Enterprise Architecture goes from a lengthy process of organizing a time, exporting data etc, to a few button presses, and an automated email or notification.

And a number of other quality of life benefits…

Such as:

  • Stakeholders can contribute EA model data themselves
    • If they’ve have been given permission by the tool admin that is. This is beneficial as they might have knowledge of missing or out-dated attributes. This is better than the traditional method where stakeholders could see the EA model data but couldn’t engage or contribute
  • The ability to see in real-time when another team member or a stakeholder is viewing the same diagram, roadmap etc
    • This helps avoid any confusion in who’s working on what, and further eliminate duplication
  • Permissions – Being able to define exactly who can and cannot see data in the tool
    • Access can be restricted by customized parameters, e.g. by geography. In this case, stakeholders in the Australia office for example, can only view EA model content related to that location

As we accelerate towards a new era in digital business with the adoption of IoT and other technologies, Enterprise Architecture is going to be more in demand than ever. However, the old way to approach EA isn’t sufficient enough to support this. We need to approach EA greater emphasis on agility and collaboration.

collaborative enterprise architecture

Categories
erwin Expert Blog

Why View Managers are a Must in Enterprise Architecture

Enterprise Architecture (EA) trends towards increasing organizational agility, driving technology innovation and delivering business outcomes have helped to make the domain’s value more obvious to the wider stakeholder community.

Not only that, but Enterprise Architecture’s value is now being realized a lot sooner than before amongst less mature organizations, to show a Return on Investment (ROI). That said, there’s still room for improvement, and the domain can still benefit from a number of quality of life improvements to finally shake its ‘Ivory Tower’ perception once and for all.

The adoption of a “View Manager” is one such quality of life improvement Enterprise Architecture could stand to benefit from. We’ve already seen Views revolutionize the way we navigate other enterprise tools spanning from Customer Relationship Management (CRM) to Business Intelligence (BI) tools and many others inbetween. Enterprise Architecture’s adoption of the concept is a natural step.

What is a View Manager?

In short, a “view manager” streamlines the navigation and presentation of information, allowing a user to save a number of customized representations of data to be both recalled, and/or reapplied to other data in the future.

Any Enterprise Architect is aware of just how complex an enterprise’s architecture can get. This streamlining of information will enable EA’s to view model and object data (among other types) on a snapshot basis, as well as enable these snapshots to be cycled through readily.

Enterprise Architecture View Manager Dashboard

View Manager in Collaborative Enterprise Architecture

Coupled with a tool supporting collaboration, the benefits of View Managers are even greater still. They help usher in the democratization of EA, facilitating greater engagement of the wider organization directly inside the tool.

The ability to share views means that those with the insider knowledge of the tool – the experts, the main users – can set the parameters of the view(s) on behalf of others (stakeholders, decision makers, relevant parties, etc). This makes things substantially easier when communicating the data as everybody can see the same representation of the information, without all parties needing expertise in the domain.

Data snapshots can also be shared quickly and easily to avoid the common problem of over-complicated EA. A best practice of communicating Enterprise Architecture, and generally any domain requiring expertise, is communicating only what stakeholders/business leaders/etc. need to know.

However, this isn’t indicative of shady practices. On the contrary, what is meant by this, is that the relevant parties aren’t shown irrelevant data. This redundant data can lead to a messy, and generally unagile architecture that can be difficult to comprehend for EAs themselves, let alone non experts.

Using Views as snapshots of the architecture can help avoid these issues, and the best part about it is, once the view is made, it can be applied and re-applied over and over again in an instant.

Examples of Views applied to Enterprise Architecture

Thanks to their innately customizable nature, there can be many different uses for views, depending on how the user tailors them.

A typical example found as a default option in most tools supporting views is “My X” – where X is a data type you operate in. In Enterprise Architecture, X would often be “My Applications”. In a collaborative Enterprise Architecture set up, this is a great quality of life feature that allows the architect to quickly pull up only the models/diagrams/etc assigned to them.

Another example could be “Top 10 risks.” In this case, instead of the ownership or assignment value being relevant, this view is determined by the value of risk. There are many cases in which this view would be extremely valuable. One such example could be internally (within the EA team) deciding on the priority of certain issues.

Architects could couple this with business capabilities to see which risks could potentially be lessened, or even nullified and in turn, use this information to devise the best plan of action.

For similar reasons, this view would also be relevant when communicating with business decision makers and stakeholders.

Business capabilities themselves could also benefit from such views. For example, ‘X Department Business Capabilities’ could display the business capabilities relevant to a specific department.

And these are but a few examples. Views can be designed in minutes for ANY object type and with ANY set of rules in the system, and then saved for future use. The diagram below shows a visual representation of views and their use.

Enterprise Architecture Views Breakdown

In some cases, an application, object or diagram might meet the criteria of more than one view. In this case, the information is present in both. The example above only shows views with information ordered linearly, but in reality, the information going into the view can be a lot more chaotic. That’s why the end result is so much easier to comprehend. The views show a far more focused representation than is possible without.

As with other types of enterprise software, Enterprise Architecture tools with baked in View Manager support will become the new normal. It’s a fundamentally more efficient and more simple way of interacting with data, for a domain that’s notoriously difficult to encourage outsider engagement.

For the expert, ‘views’ make it easier than ever to group, manage and focus EA information. This in turn benefits the non expert too, as stakeholders, decision makers and other relevant parties aren’t burdened with information that isn’t relevant to them – they see less ‘noise’ and can zero in on what is important. They’re also given simpler access into the tool itself, as views can be set up and customized on their behalf.