Interoperability and challenges in R&D (4/4)

Benefits and challenges of exposure dimension

The following schema illustrates the main elements of this dimension:

image

Benefits and challenges of platform dimension

The following schema illustrates the main elements of this dimension:

image

Challenges synthesis in R&D

To conclude, the main challenges in interoperability in R&D for software’s publisher are resumed as following:

Systematic challenges:

  • Skills availability
  • Development costs
  • Tests costs
  • Support costs

Potential challenges:

  • Availability of test platforms for cloud-based solutions
  • Availability of test platforms configured for heavy solutions
  • High complexity level in the case where you have to support numerous combinable technologies
  • Increased difficulties of exposure, especially in the "API" mode which requires a very specific technical know-how and a rigorous industrial software release process.

Interoperability and challenges in R&D (3/4)

Dimensions of interoperability

The interoperability presents four dimensions illustrated in the following schema:image

In the first hand, interoperability is about benefiting from someone else’s software (i.e. bottom and right parts). On the other hand, it’s about allowing third-party software using ours (i.e. top and left parts).

On the vertical axis, we represent what constitute dependence and not only a possibility. We can depend on a platform or position ourselves as a platform. This distinction is really important to distinguish to measure challenges.

Otherwise, we’ve placed indexes going from 1 to 4 which take care of the “natural” order wherein the interoperability is usually approached by software publishers.

  1. Dimension 1 is almost necessary for every software publisher at least to rely on a database or an operating system.
  2. Dimension 2 seems rapidly necessary to be integrated into customer’s legacy environments.
  3. Dimension 3 becomes important as soon as we offer a service usable by third-party and we start to have a certain market position.
  4. Dimension 4 is the final step and potentially the “holy Grail” of success. It needs a really great know-how because you need to provide reliable APIs over time. It also requires a strong market position because software publishers who are going to use your platform needs a strong confidence to accept being dependent of the underlying software.

Benefits and challenges of deployment dimension

The following schema illustrates the main elements of this dimension:

image

Benefits and challenges of consumption dimension

The following schema illustrates the main elements of this dimension:

image

Interoperability and challenges in R&D (2/4)

The cultural component

Besides technical aspects, the cultural component is often a point you shouldn’t forget if you want your project requiring interoperability between different technologies to be successful.

Technical interoperability is like using a common language. It doesn’t rub the cultural differences.

With our clients, we have observed a lot of different contexts in the field, each bringing new difficulties to make completely different computing cultures to cooperate.

For example, some real life cases we worked on:

  • Huge mainframe system back-end integration with a Windows web server in the front,
  • SharePoint-based application using SAP processes,
  • Rich .NET client used to manipulate decisional data of a SAS repository on Unix,
  • iOS application using a full .NET back office and exposed through JSON/REST services.

Coming from different backgrounds, with different cultures and working styles, co-workers often feel hard to communicate, even just to implement the test process to validate the systems that need to interoperate.

In practice, it often takes a person to bridge the gap, someone who has already worked on both universe, or curious enough to get interested on a new set of technology and then acquiring skills to understand the big picture.

Global Benefits

There are plenty of benefits for software’s publishers in interoperability:

image

Benefit 1: Integrate into customer’s legacy

The first benefit of being interoperable for a software publisher is to allow integration into customer’s legacy environment.

In the IT, the inertia is really high and therefore the obsolescence curve is way longer than the forecast.

The existence of operational and validated systems, the importance of real production data and the habits acquired by users make any movement risky, and inevitably, economically costly in the short term.

So, one of the most important solution choice criteria is to ensure minimal disruption to systems that work.

Therefore, every solution which can integrate with the legacy, evolving step by step, has a major asset to be considered as compared to those who can’t.

Benefit 2: Enlarge your targeted market

The second benefit of interoperability, platform-wide, is to enlarge your targeted market by supporting a maximum of the platforms available as:

  • Databases,
  • Middlewares,
  • Operating systems,
  • Web browsers,
  • Mobile platforms,
  • Cloud platforms.

With a lot of investment, a software publisher can enlarge its target by diversifying platforms where its solutions works on, because many customers impose or favor one technical environment or the other.

Benefit 3: Optimize the value/cost ratio and invest in differentiation

The third interest in interoperating with other software suites is to focus your effort on the differentiation. Levering other software pieces that are doing great with some transversal or mature functions, we can invest our energy, time and money developing more accurate functionalities which will make our offering unique.

Depending on the sector and the application type, this kind of approach can be optimal in terms of generated value for a given cost.

It’s the principle of “best of breed” and effort concentration on the best element for a given sector.

Benefit 4: Comply with any regulatory requirements

Finally, you’ll have to remember that interoperability is often a regulatory requirement.

In a lot of businesses there is regulation to protect customer from being captive of a publisher who’s using too much proprietary formats.

Depending on the market situation, some legal work made sometime necessary to maintain the competition. Depending on the region, there are various laws to protect interoperability, from format regulations, to decompilation authorization, not to mention the very visible anti-trust actions that sometimes target the giant companies.

The lawmakers try to preserve a balance between intellectual property protection and the assurance of a competitive environment serving customers interest.

Interoperability and challenges in R&D (1/4)

Following a presentation made as part of my activity with the French association of software publishers last December, here is a series of articles containing the ideas developed during this speech.

3 good reasons to get interested in interoperability

Interoperability itself isn’t a new subject. Set on the systems border, as these are hardware or software, the problem has technically been asked since the beginning of the computing science.

Addressing this challenge is necessary for software’s publisher, today more than ever, since it is often complex and multiform, and not only on the technical aspect.

image

Reason 1: platform fragmentation

The first reason to get interested in is the background trend concerning the multiplication of platforms.

Indeed, with the strong supremacy of the couple Wintel until the half of the 2000, interoperability had lost a bit of its emphasis in some areas.

But it is clear that Microsoft lost ground on part of the platform during the last years. Of course, Windows and PC are still dominating the market, but the multiplication of devices, especially mobile ones, changed the rules of the game.

No doubt that the tablets aren’t going to make it better, and even if Microsoft works hard on it with Windows 8, it’s almost sure that a market with only one system provider seems to be behind us… In a near future at least!

Even concerning the PC, the plurality of web browsers, something we could have legitimately believed to be over, is back with all the technical issues it implies for developers.

All this brings interoperability technical challenges platform-wide with intrinsic complexity.

Reason 2: specialization

The second reason of a major come back of the interoperability is the specialization. Each business growing, software’s offers become more and more verticalized and specialized.

Nowadays, it’s almost impossible to satisfy client needs within a single integrated offer, even for leading publishers who have large offerings. By the way, in most cases, these don’t have a consistent offer, since they grew through successive acquisitions, and interoperability issues appears even inside the product lines.

Moreover, largest solutions are penalized by a sort of inertia and are convicted to be late comparing to emerging offers which are more accurate. Consequently, clients are looking for the best of breed to answer their needs.

Ultimately, the optimal solution for a client goes through software’s composition, posing the interoperability challenge concerning data and processes.

Reason 3: the cloud computing

The third and last reason is the emergence of cloud-based models. Even if this model is in its early stage in many sectors, the underlying trend has begun and the cloud computing is going to raise new interoperability challenges at platform and application level.

No doubts that Facebook itself becomes on its own a development platform, and -side Salesforce has already become one in business-to-business for several years.

This transition to the cloud will probably be achieved with plenty of hybrid solutions, at least while those solutions are not thoroughly functional.

Consequently the result will be a lot of significant interoperability challenges between the on-premise and cloud-based infrastructures, not to mention a likely distribution between different providers.

Different types of interoperability

Otherwise, it’s important to understand that there are different types of interoperability.

In the first place, there are differences in formats. For instance, HTML, XML, ODF, CSV or PDF are files formats. This allows software suites to recognize the type of data they’re dealing with.

Communication protocols are also important in interoperability. HTTP, FTP, POP, IMAP or SMTP are well-known protocols since they’re allowing communications between different systems.

From development side APIs, generalists like JSON/REST or specific to a provider like for the .NET platform or WinRT, allow developers to use applications functionalities without caring about how the program works internally.

Finally, some business-oriented functional models are more or less standardized like HL7 (e.g Health Level 7) in health sector.

In the end, interoperability has different flavors depending on the level you’re looking at it.

Standards and limitations

To guarantee the interoperability between providers, some of these notions are standardized through different organizations like W3C, ECMA, ISO or IEEE. In lot of vertical sectors, consortiums exist for data exchange processes and formats.

But the standardization processes or normalizations are necessarily slow and always late regarding to the latest technologies because of:

  • The computing complexity,
  • The divergence of interests,
  • The rapid pace of innovation that doesn’t wait for validated agreements.

In some cases, standards are far from being useful anymore or simply useless. CORBA is an example of a failed standard. It looks like UML is taking the same path.

April 11th 2012 Links: VB6, .NET Portable Class Libraries, Internet Explorer 10, ASP.NET MVC 4, eBooks

Following the steps of Scott Guthrie’s link-listing series, here’s our new batch of links in our own series:

 

Windows

Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008, Windows 7, and Windows 8

Good news for those still using VB 6: it’ll be supported on Windows 8!

 

It’s the end of mainstream support for Windows Vista

April 10, 2012: That’s the date Windows Vista support moves from mainstream to extended (meaning paid for everything but security updates).

 

Visual Studio

Hidden Gems in Visual Studio 11 Beta – .NET Portable Class Libraries

Scott Hanselman details Portable Class Libraries which is a feature available in Visual Studio 2010 (through an extension) and in Visual Studio 11.

 

TFS 11 Power Tools Beta Available

Good news TFS 11 power tools (beta) are now publicly available Smile 

 

Dev

ASP.NET MVC 4 now open source

Yay! All sources are on CodePlex! if you haven’t already, go check them out because that’s some good looking .NET code Smile

 

The Danger of the Large Object Heap (LOH)

Another article which we like on the same subject is: “Large Object Heap Uncovered” (written by Maoni Stephens).

We actually wrote an article ourselves which is quite related to the subject as well: Manipulating SQL Blobs With Streams.

 

IndexedDB Updates for IE10 and Metro style apps

IndexedDB is a W3C Working Draft that enables you to store, search, and retrieve data on the user’s device, even when Internet connectivity is disabled.  IndexedDB is a feature of the Web platform shared by IE10 and Metro style apps in the Windows 8 Consumer Preview.”

Hmm, very interesting…

 

eBooks

Grab a free copy of “Under the hood of .NET Memory Management”

We did it, it was worthy, so we thought we’d share Winking smile

 

Free ebook: Introducing Microsoft SQL Server 2012

With SQL Server 2012 now available, I’m sure it’ll come in handy.

 

Cheers,

Carl Anderson

Anemic Domain Models

From our experience as technical auditors, we noted more and more frequent situations where we observe “Anemic Domain Models”. Driven by a lack of understanding of the “Separation of concern” principle, it seems that some unexperimented developers tend to over-create classes applying what they have understood of architecture principles in a very clumsy and ineffective way of coding.

Let’s come back to basic as described a few years ago by Martin Fowler in his post :

The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.

That’s exactly what we try to avoid in our projects: those business logic empty classes, often wrapped in an extra layer of procedural services, which in the end just create a procedural style design. Furthermore, as many people think that anemic objects are real objects, thus completely missing the point of what object-oriented design is all about.

image

Instead, as Eric Evans states about the Domain Layer (or Model Layer):

Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

And we completely agree: especially right now, on the verge of a new technology wave (e.g. HTML5 & WinRT) the real key is your architecture. If you already have this rich domain layer, upper layers should just be consumers of it, empty shells providing user interaction to the heart of your business software. Consequently supporting a new platform (going from desktop to web, or Web Forms to MVC for instance) gets down to creating this new shell.

That’s exactly the reason why we created CodeFluent Entities, with the first goal of generating a real .NET Business Object Model: it generates a full .NET domain layer containing your business logic and which can be used across all .NET technologies (Windows Forms, WPF, SharePoint, ASP.NET MVC, ASP.NET Web Forms, Windows Workflows, etc.) this way securing your investments.

This is possible as the Business Object Model producer (= code generator) can generate:

  • Classes: plain old classes (not deriving from a base technical class), human readable, that are all partial and meant to be easily extensible by developers, implementing an extensive set of interfaces (ICloneable, IComparable, IDataErrorInfo, IEquatable, INotifyPropertyChanged, etc.) to ease development of upper layers, and easily debuggable as no code is dynamically generated at run time
  • Enumerations: since CodeFluent Entities is not an ORM, you can create your own .NET enumerations or reuse existing ones,
  • Multiple namespaces: as its common to have more than a single domain in real enterprise class applications,
  • Rules: to validate your data, set-up transactions, and implement your business logic,
  • Methods: create your own methods aside default generated ones,
  • light objects as structures or non-persistent objects useful to gather-up cross entity information,
  • components as a binary large object http handler to manipulate blobs in web environments, or a cache manager based on the standard ASP.NET cache manager, and more.

Last but not least, we don’t think that tools can generate entire enterprise-class applications, that’s not what we’re saying, developing applications is a complex operations that needs more than data access and/or UI controls. Instead what we’re saying is that we provide a tool to developers which helps them set-up rock-solid foundations for their .NET applications, built on a consistent domain model, which developers will have to extend and fill-in the gaps.

The recipe we provide through CodeFluent Entities ends-up creating .NET applications based on a rich Domain Layer built by the tool and developers, containing the full business logic of your application. It’s a complete and consistent API which can be used on all platforms (x86, x64, desktop, web) across all technologies (.NET 2 to 4) this way securing your investments.

And even if you are not considering using our tool, we still think it is a very bad idea to follow this path of “Anemic Domain Models” and that you should create real domain models, either by hand or by finding another tool can do it the right way.

Daniel COHEN-ZARDI, with the support of the R&D team

SoftFluent at Devweek 2012

Devweek_2012(1)Devweek_2012(2)Devweek_2012(3) SoftFluent sponsored Devweek 2012 event last week in central London, United Kingdom.

This was a good opportunity to have productive discussions with UK developers interested in knowing more about CodeFluent Entities

Most of traditional .NET ecosystem partners were there such as JetBrains, Redgate or Telerik.

Additionally, our booth was next to our two main partners: Infragistics and Pluralsight. So everything turned out perfect!

This was definitely a great event, thanks to the organization team and looking forward to next year edition!

The SoftFluent event team

CodeFluent Entities supports Visual Studio 11 Beta & SQL Server 2012

get-vs11betasqlserver2012logo_01A70123012213812 SoftFluent announced today at the DevWeek conference that CodeFluent Entities runs in the Microsoft Visual Studio 11 Beta.

Furthermore, the SQL Server code generator now supports Microsoft SQL Server 2012 RTM.

By leveraging CodeFluent Entities, developers can put the burden of keeping up with new technologies on the product, while focusing on developing the features they need for their applications.

Read the full Press Release

Follow

Get every new post delivered to your Inbox.

Join 183 other followers