Search Results for: business model

Enterprise Architecture Roadmap for success: Tooling

by

<p><span style=”color: #505050; font-size: 11px; line-height: 19px;”>In this eighth posting we will cover the topic of <a title=”BiZZdesign Architect” href=”http://tools/bizzdesign-architect/”>Enterprise Architecture Tooling</a>. First we will explore the question what capabilities effective Enterprise Architecture teams need from tools, and list some characteristics that tools need to have in order to efficiently support Enterprise Architects. In the second portion of this blog we will address best practices that Enterprise Architecture teams can use to fully leverage the power of Enterprise Architecture tools.</span></p><p> </p><div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600375-Enterprise-Architecture-Tooling.png” alt=”Enterprise Architecture Roadmap for Success Contents” title=”Enterprise Architecture Roadmap for Success:” width=”600″ height=”375″/><p class=”caption”>Enterprise Architecture Roadmap for Success: part eight; Tooling</p></div></div><h2>Many Enterprise Architecture aspects</h2><p>From <a title=”Blogs by Sven van Dijk and Bas van Gils” href=”http://www.bizzdesign.com/blog/posts/bas-van-gils-and-sven-van-dijk”>previous postings</a> in this series it has become clear that Enterprise Architecture has many aspects, and that the specific set of aspects to focus on greatly depends on the approach that an organization takes with respect to Enterprise Architecture. For example more strategic aspects in a top-down approach and more operational aspects in a bottom up approach.</p><p>But in general we could state that Enterprise Architecture is always about knowledge and communication. Enterprise Architecture brings together various perspectives, enabling integrated analysis on the current and future state of the architecture of the enterprise. This results in valuable knowledge that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly: in the right format. An essential aspect in Enterprise Architecture is stakeholder communication. Enterprise Architecture has a diverse audience including business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is clearly understood.</p><p>This gives us directly a number of essential qualifications for Enterprise Architecture tools: rigidity when it comes to the management and maintenance of knowledge, and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation and communication of the knowledge to diverse audiences.</p><p>So what you are looking for is a tool with solid repository capabilities, and flexible modeling and analysis functionality:</p><ul><li>Options to create manageable partitions of Enterprise Architecture knowledge such as models. Definition of these partitions should be flexible and fully customizable, while the tool offers functionality to make sure that integrity of the data over the various partitions is not compromised;</li><li>Management of versions, including life cycle (draft, approved, etc.), but also versions in time (current state, future state, etc.);</li><li>A metamodel that possesses just enough formality to model all aspects of the enterprise  (business, people, processes, technology) in a coherent and meaningful way, but is on the other hand flexible enough to customize and tailor to cover capturing organization specific information;</li><li>Flexible and ad-hoc modeling and analysis functionality is essential to deal with the various questions and concerns that stakeholders have regarding the Enterprise Architecture;</li><li>Reporting and communication features capable of slicing and dicing the knowledge in any way, and little restrictions on the format in which the knowledge can be presented to various audiences;</li></ul><h2>A single Enterprise Architecture tool or a set of tools that supports Enterprise Architecture?</h2><p>In the tooling business there are many vendors, some of them claiming to offer one-stop-shop Enterprise Architecture solutions. Given the diverse functionality that Enterprise Architecture needs, and the myriad of approaches organizations take on Enterprise Architecture based on their priorities, a one-size-fits-all solution does not often seem the best choice.</p><p>Take for example document management capabilities to support Enterprise Architecture governance on the one hand side, and multi-faceted ad-hoc model querying to support complex design decision making on the other hand. When trying to cover both in one tool you don’t usually get the best of the both worlds.</p><p>Often it is better to select a small number of specialized tools that can be aligned so that together they support the full spectrum of capabilities that Enterprise Architecture needs. This can sometimes be found in a “tool suite” from one vendor. But if the organization wants more flexibility to choose the best tool, they usually end up with tools that support open standards so that they can be easily aligned with other components in the organization specific Enterprise Architecture tool set.</p><p> </p><div class=”captionImage left” style=”width: 600px;”><div class=”captionImage left” style=”width: 600px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600498-Enterprise-Architecture-Repository.png” alt=”Enterprise Architecture Repository” title=”Enterprise Repository, Architecture Repository” width=”600″ height=”498″/><p class=”caption”>Enterprise Architecture Repository</p></div></div><p><a title=”TOGAF®, The Open Group Architecture Framework, is a proven, comprehensive and generic methodology and framework.” href=”http://consultancy/enterprise-architecture-management/togaf/”>TOGAF’s </a>description and depiction of the architecture repository gives a good overview of what the architecture content is that needs to be created, managed and maintained in an enterprise architecture environment. The architecture landscape often consists of descriptions using models to express the architecture on various levels: strategic, segment, and capability. Other model content includes solution architectures in terms of building blocks, and a library with reference models. The models are based on the organization specific meta model. Other types of data in the architecture repository include architecture requirements, a library of standards, governance data and data describing the architecture capability itself.</p><p>The architecture repository is often a conceptual thing rather than a physical implementation on a single database. Often, a set of tools are in use in an organization to support various processes and management of various types of data. The tools are aligned, e.g. based on the structure suggested by TOGAF, so that together they form a complete solution supporting the Enterprise Architecture capability.</p><h2>A fool with a tool…</h2><p>In this final part of this posting we want to address the actual use of Enterprise Architecture tools. In our practice we sometimes see organizations looking for off-the-shelve solutions that “do” Enterprise Architecture for them. It may sound as an open door, but in our opinion a tool should support enterprise architects so that they don’t have to bother about simple, straightforward, and activities with an administrative character. In that way, they can focus on the real design challenges that the organization faces: the activities with which Enterprise Architecture actually adds value to the organization. Talented and intelligent enterprise architects are those who ask the right questions, and who can reduce complexity with smart models. Tools should make the life of these architects easier by being flexible, supportive, and not imposing all kinds of cumbersome activities for simple tasks. Some Enterprise Architecture tools claim to automate the intelligent design work, and that Enterprise Architecture automatically “happens” once installed on the companies’ servers. In practice this is rarely the case. Effective architecture is all about the right architect using the right tool in the right way, or as we sometimes say: a fool with a tool is a still a fool making faster disaster.</p><p> </p><div class=”captionImage left” style=”width: 301px;”><img class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/Fool-with-a-Enterprise-Architecture-Tool-.png” alt=”Enterprise Architecture Fool with a Tool” title=”Enterprise Architecture Tooling” width=”301″ height=”222″/><p class=”caption”>Enterprise Architecture Fool with a Tool</p></div><h2>Next posting</h2><p>If you’d like to know more, please contact the authors directly at <a title=”E-mail Bas van Gils” href=”mailto:b.vangils@bizzdesign.com”>b.vangils@bizzdesign.com</a> / <a title=”E-mail Sven van Dijk” href=”mailto:s.vandijk@bizzdesign.com”>s.vandijk@bizzdesign.com</a>, or leave a comment. The next post in this series is about using consultants for building Enterprise Architecture practices. It is scheduled to be posted between 11<sup>th</sup> and 15<sup>th</sup> of March.  </p>

Categories Uncategorized

Why Becoming Social Isn’t Just For Woolly Headed Idealists

by

In my last article, ‘Love in the Time of Cholera: How to do Business in a Recession‘, I sketched out what being a social business is about and made the claim that making the change to such a model might be a reasonable response to the current state of the world. Social business can sound pretty idealistic and […]

Four principles for a sane society: an addendum

by

What architectures do we need for a society and economics that’d be viable and sustainable over the longer term? And how do we scale that down to the the everyday work we do at present in enterprise-architectures and the like?…

CfP TEAR 2013

by

TEAR 2013 – 8th Trends in Enterprise Architecture Research Workshop The TEAR workshop is organized in conjunction with the 17th IEEE International EDOC Conference (EDOC 2013) 9-13 September 2013, Vancouver, BC, Canada *** Deadline for submissions: April 15, 2013 *** Motivation The international TEAR workshop series brings together Enterprise Architecture (EA) researchers from different research […]

Deep Thinking on The Architecture of Architecture: Meta-Architecture

by

As many of you have already have known, Enterprise Architecture and Architecture within the context of sociotechnical organization is going through what I believe a renaissance period.  
The architecture field is moving to more of an in…

Four principles for a sane society: Summary

by

How do we make sense of the big-picture in enterprise-architecture? The really big-picture? For those who didn’t (or couldn’t!) read the full series, here’s a (shortish) summary of each of those (rather over-long) posts… From the Introduction Part of the work I’ve been…

Deep Thinking on The Architecture of Architecture: Meta-Architecture

by

As many of you have already have known, Enterprise Architecture and Architecture within the context of sociotechnical organization is going through what I believe a renaissance period.   The architecture field is moving to more of an interdisciplinary art and science.    Also many architects, myself included, have been trained on producing goal oriented systems.  This teleological approach based…

Four principles – 4: Adaptability is everything

by

How do we work with change – and, especially, extreme-change – in an enterprise-architecture? At the really big-picture scale? This is the fifth in a series of posts on principles for a sane society: Four principles for a sane society: Introduction Four principles: #1:…

Framework for Service Oriented Ecosystem

by

I note interesting debates about the need for a next generation EA framework. However I am disappointed by the less than radical nature of debate that, at least I, have observed. I submit a good place to start is with the fundamental nature of business and how it is evolving and to consider what the enterprise of the future looks like. There are many indicators that we are entering a new phase of IT exploitation that will represent a real paradigm shift. Paul Krugman suggests IT is at last becoming significant, enabling a technology revolution to rival previous technology revolutions. Krugman cites driverless cars as an example of the technology moving into the physical world that has the potential to power growth. I will also instance a wave of disruptive technology delivering high bandwith always on connectivity for billions of workers and consumers, mobility, BYOD, social networks, big data and next generation analytics, robotics and Cloud. And the widespread adoption of Agile methods is also highly significant.

This stream of disruptive technologies is having a major impact on enterprises and the way they work. A Gartner report released this week predicts that by 2017, 25 per cent of enterprises will have enterprise app stores where workers can browse and download apps to their computers and mobile devices. I think that prediction will turn out to be conservative. It’s striking that many if not most enterprises are already being run as a continuous stream of initiatives, driven by business competitive pressures which in many cases are triggered by the disruptive technologies mentioned. And strategic innovation is typically being delivered in Agile projects which will increasingly combine business and IT expertise in defining the architecture and requirements.

But this is still a conventional view, doing what we do today, faster, better cheaper. What’s more importantly is to look at how the technology will enable profound change that spans existing enterprise boundaries. Consider Krugman’s Driverless Cars. This revolution is set to change the shape of personal transport in the relatively near term and will involve capabilities such as telematics, insurance, road tolling, mapping, navigation, vehicle recognition, which span car manufacturers, the financial industry, local or state government, emergency services and so on. This is a new ecosystem in the making which will require near real time, collaborative services spanning multiple business sectors.

Is this driverless cars ecosystem an isolated revolution? I don’t think so; consider smart shopping which is already taking off like a rocket with showrooming, or the extension of mobile devices to sector specific applications such as drug testing, health monitoring. I could go on. The future is going to look like many, many ecosystems, rapidly evolving usually not in the control of a single enterprise.

So returning to the question about a next generation EA framework, we might put a few stakes in the ground:
1. The pace of change is increasing so fast that conventional approaches (frameworks) for modelling will be left behind.
2. Ecosystem architecture should be primarily about identifying how an enterprise leverages an ecosystem by providing capabilities and their business services that collaborate and evolve along with the wider landscape.
3. The future is “business service” oriented. The application is dead. Business Service Implementation would be a better term.
4. The Capability and Service architecture will be a strategic business asset.
5. Capabilities as highly independent units of business function will be the way the business is organized.
6. The primary task of enterprise architects will be to develop the Capability and Service architectures as part of the business design.
7. Enterprise architects will probably be renamed Capability and Business Service Architects and report to the CMO.
8. The framework scope must span the entire Agile life cycle. Architecture is no longer a top down precursor to delivery, it must be an evolving set of deliverables and inherently implementable. The framework therefore needs to support concurrent development of business requirements, ecosystem, service and solution architecture, modernization, plus service and solution specification and delivery.

What’s needed is a new framework that recognizes the enterprise itself is a series of overlapping business ecosystems that are in turn part of a series of ecosystems that transcend the scope of the enterprise itself. A new framework should be focused on the capabilities and their inter-connections and manage the development of the business ecosystem(s) to the advantage of the enterprise.

While Capability is a widely used concept, notwithstanding some significant divergence of definition, the missing link is the realization of the Capability. In our work we use the Business Service concept – which delivers the capability in a context free manner. It’s extraordinary that our business vocabulary doesn’t include the formal Business Service concept in the same way that we are able to talk unequivocally about Business Process and know we will be understood.

The core model underlying the framework for future business needs to be service oriented, but it’s essential that the model is fully integrated with business concerns, and enables an implementable architecture in a way that current EA models manifestly do not. The new framework is also highly supporting of Agile methods in the entire life cycle being lightweight, twin track, narrow scope based on the Capability and Business Service, and contract based dependencies.
We will be running a workshop that explores these ideas in London in April in conjunction with the IASA UK Summit. If you can’t make the London event, (for geographic of schedule reasons) talk to me about how we can accommodate.

Paul Krugman: We Are On The Brink Of A Technology Revolution That WillTransform Our Economy


JEA XL: Journal of Enterprise Architecture 2013-1

by

Back in November 2012, as chief editor of the Journal of Enterprise Architecture, I faced an ebb in qualified submissions and decided to postpone the next number. I solicited more submissions and soon decided that a way to make up for a missing number would be to release an extra thick “double-issue” – JEA XL. Almost …read more

Designing the next programming language? Understand how people learn!

by

Somehow it is a recurring theme in computer science: create a “programming” system that is easier to use and learn than the existing programming approaches. I am not just talking about better tools, like IDEs, but also new languages. It seems as if each self-respecting programmer creates his/her own language or tool-set nowadays, right?

Okay, I have to admit that not all efforts are focused on making things easier, often the focus is on productivity. However, if we, for example, look at the “programming” languages created in the Model-Driven Development there, we see quite some focus on involving domain experts in development by creating higher level, domain-specific, or sometimes even visual languages. Although there are much more reasons to do Model-Driven Development, it is the ease of use and the lower entry barrier that captures the imagination.

There is a fundamental flaw in our thinking around these approaches, though…

Language fundamentals

Let’s look at the fundamentals of a language before we dive into the details. A language specification consists of three main elements:

  • Concrete syntax: the concrete syntax defines the physical appearance of language. For a textual language this means that it defines how to form sentences. For a graphical language this means that it defines the graphical appearance of the language concepts and how they may be combined into a model. Multiple concrete syntaxes can be defined for the same language. You could, for example, define both a textual and a graphical concrete syntax.
  • Abstract syntax: the abstract syntax defines the concepts of a language and their relationship to each other.
  • Semantics: the semantics describe the meaning of a sentence or model specified in some language. In the context of programming this means that the semantics of a language describe what the effect is of executing the statements of that language.

All these elements play an important role in how easy it is to learn a language.

How do we learn a new programming language?

In general we learn in a number of different ways. Up to 10 different learning styles have been defined, but I think they can boil down to 3 main styles:

  • Listen: let someone educate you.
  • See: read stuff, watch someone else do it.
  • Experience: just start and try it yourself, experiment, trial and error.

Most people combine multiple styles when they learn something new.

Let’s go one step further: when do people understand how something works (we are not talking about factual knowledge here)? If they hear, see, or experience cause and effect. That’s when we connect the dots. If you hit a play button and the music starts to play you understand the function of that button, and if you hit different kinds of buttons on different systems that all lead to “the music starts playing” you will probably understand that the triangle icon means “play”.

When we learn how a system works or more specifically when we learn a new programming language, we can have different learning styles, but in the end it is about relating cause and effect. Whether you hear someone explain it, see someone do it, or experience it yourself.

The difference between simple and complicated, and thus easy or difficult to learn, is due to the “distance” between cause and effect. If there are many steps between cause and effect it can be difficult to connect the two. If a “system” is a black-box with multiple inputs and outputs, with a complex relation among inputs and outputs it is difficult to determine cause and effect and hence it is difficult to understand the system.

If we want to create a new programming language that has “easy to learn and use” as a core design principle, we should aim our efforts on an easy-to-understand cause-effect relationship between language concepts and the actual semantics of the language.

Let’s see how approaching a language from this angle influences concrete syntax, abstract syntax, and semantics.

On concrete syntax: how does it convey meaning?

Most discussions (and/or flame wars) around languages are focused on concrete syntax (sometimes combined with discussion about abstract syntax because there is a close relation between abstract and concrete syntax in most languages). Syntactic sugar like white-space and symbols as well as how concise the language is, are hugely interesting discussion topics

Our main question around concrete syntax, however, should be: how does the language convey meaning? If we read the language, do we know what the words mean? Do we understand the meaning of the data (inputs, variables)? Can we easily follow the flow? These are the things that matter!

You want examples you say? Well, this may be the worst readable language of all, that’s the goal at least. The microflow language we use in our platform is a bit easier to read and understand and hence conveys the meaning of the program much better (and it even leads to art).

On abstract syntax: being declarative is not the holy grail

In the world of Model-Driven Development and Domain-Specific Languages the focus tends to be more on the abstract syntax. The core tenets of Model Driven Development, or Model Driven Engineering if you will, are abstraction and automation. Normally if you want to create a language that is easy-to-use by domain experts (often non-programmers) you focus on creating an abstract syntax that leaves out technical details and is as declarative as possible, right? Do not focus on technical details (abstract them away) and specify the “what”, not the “how” (declare the program).

However, abstracting away technical details does not automatically make a language easier to understand. It all depends on what the relation is between the language concepts and the actual behaviour of the application you see (remember: cause and effect). A low-level language creates too much of a distance between cause and effect as, for example, machine-level instructions are not easy to relate to application behaviour. On the opposite side we have language that are too high-level and thereby create a difficult relation between cause and effect too. If one line of code (or a single activity in your process diagram) leads to the execution of a range of actions that can result in a plethora of results, it can be hard to grasp the impact of changing something.

This leads us to the subject of declarative languages. Declarative languages can be very powerful as you just declare the result, not how to get it. Example languages are SQL (well-known, more declarative than procedural), Prolog (if you studied computer science you probably know it), or the languages used by most business rule engines. The nice thing about declarative language is that you abstract away all the “how”, you avoid implementation details. What these languages promise is that programs created with them are easier to understand and maintain, and sometimes that’s completely true.

However, what always bugged me is that users of our App Platform learn to use our procedural DSLs quicker than the more declarative ones. In hindsight that’s maybe not that difficult to explain. It’s probably best understood if you imagine a large system that consists of 1000 rules (or predicates) that are automatically woven into a working system. Do you think a “programmer” can easily connect cause and effect when changing a rule? The lesson: being declarative shouldn’t be a goal on its own, it can even make things more difficult if not applied well. Please note that I focus on the learnability of the language; productivity, conciseness, etc. are different considerations that may influence your choice for declarative languages.

In the end, the abstract syntax of a language should help to reason about the problem you are solving using the concepts of the language. It should be a proper abstraction of the resulting application, this abstraction can be as high-level as possible as long as this abstraction decreases the “distance” between cause and effect. The abstract syntax, the concepts of the language, should also help to decompose a problem in manageable pieces and glue them back together as a complete solution.

On semantics: live programming helps to understand cause and effect

The semantics are the most important aspect for people to learn and understand a language. Semantics connect cause (a certain language construction) and effect (the result of executing that language). As explained in the previous sections the choice for concrete and abstract syntax is important as it defines the “distance” between cause and effect and hence how easy to understand the semantics of the language are. In addition to the language itself, the tools are of the same importance in conveying the semantics of a language.

The environment you use can, for example, greatly enhance the readability of a language by providing mouse-overs, integrated documentation, highlighting, etc. But an environment should do more. It should help you to sculpt your program. It should provide refactoring options that help you to start concrete and refactor to more abstract code when needed. It should provide ways to step forward (and backward!) through the program while inspecting state and behaviour.

A great debugger can really help you to learn and understand the cause-effect relationship of your language and the actual execution. A nice example is the visual debugger we feature in our platform, and you maybe also know the Eclipse Java debugger (or even the Smalltalk debugger) that allows you to change code during a debugging session (within some limits).

Changing code and directly seeing the effects of it (dubbed “live programming” sometimes) is the ultimate way to closely connect cause and effect. If you combine that with stepping forward and backward through the execution (and thus modify state and code at the same time) you have a powerful environment that really helps a user to relate cause and effect and hence understand the language.

Warning: live programming really helps in understanding the language, but not on its own. Please do not forget the things I previously mentioned about concrete and abstract syntax. Cause and effect can be clearly connected, but if you cannot understand that connection when you read the language it will still be hard to understand the language.

Conclusion

If you want to design the next programming language that is easy to learn and use, you should first understand how people learn. The relation between cause and effect plays an important role in the learnability of a language. If you want to clarify the cause-effect relationship you should focus on both the language design and the tools.

If you like this subject you should definitely read this excellent essay (not written by me, you can safely click the link and will not regret it 😉 ) that goes into great lengths to explain how we can let people understand programming.

Designing the next programming language? Understand how people learn!

by

Somehow it is a recurring theme in computer science: create a “programming” system that is easier to use and learn than the existing programming approaches. I am not just talking about better tools, like IDEs, but also new languages. It seems as if each self-respecting programmer creates his/her own language or tool-set nowadays, right? Okay, I have to admit that not all efforts are focused on making things easier, often.

The post Designing the next programming language? Understand how people learn! appeared first on The Enterprise Architect.