By Alan R. Earls
Kevin L. Smith, the creator of PEAF, the “Pragmatic” Enterprise Architecture Framework, has a challenge: explaining a relatively unfamiliar concept, namely that there are actually two types of enterprise architectures to which frameworks can apply.
First, of course, there are enterprise architectures that focus primarily on IT issues. “Probably 90 percent of the discussions involving EA focus on IT-oriented EAs. But the fact is that IT organizations find most of their problems stem from disconnects and discontents with the business. IT organizations would be smart to help the business engage in true enterprise architecture, which is really all about strategic planning,” he says.
That’s where the other kind of enterprise architecture frameworks (PEAF is one of them) come in. This second type of EA focuses on the businesses processes across the enterprise. By contrast, IT-oriented EAs have a focus that is more granular and more relevant in the project management arena.
According to Smith, IT departments often “feel the pain” of not having an enterprise architecture and of taking the blame for all the resulting problems. Now, as more and more organizations become familiar with the ideas of an enterprise architecture, more and more IT departments are realizing that they can’t make further improvements without one. This is why some IT departments are pushing an EA perspective up to the business leaders, he says.
PEAF is based on Smith’s 30 years in the IT industry, first as a software developer, then as a systems analyst, architect and consultant. In that last role, in particular, Smith said he had occasion to witness many organizations attempting to implement IT-based EA – and every one of them failing. “PEAF was not born out of success but out of an understanding of why people failed when they tried to do an enterprise architecture,” says Smith.
Smith realized his observations could be the germ of something new so, in late 2008, he began to try to put his observations into a common format and that, in turn, grew into an enterprise architecture framework.
In the case of PEAF, Smith says the framework approach addresses all the different parts of an enterprise and its many dimensions, even including its culture. “The relationship between the business and IT is considered but it is not limited to that.” In fact, notes Smith, PEAF all but requires the employment of a second framework that is highly focused on IT. Thus, PEAF and most other EAs – such as TOGAF – are in fact complimentary.
“TOGAF will tell you what to do and how to document what you do. But it doesn’t help with the relationship between IT and business, which is more about culture and communications than it is about IT,” he contends. Of course, information technology is important for the business “but to get the whole enterprise working together is a much different challenge.”
The SOA Talk blog consistently covers new and interesting developments in the world SOA and enterprise architecture. We gleaned the cream of the crop from all of 2010 for this special on architecture, infrastructure, and application integration.
In February, the push on Wall Street was for systems that turbo-charge aggregation and pricing of financial transactions, order routing, algorithmic trading and market data management. These areas had looked like losing bets in late 2008, when banks and investment houses merged under tremendous Continued »
As we were looking at the switch from 2010 to 2011, we had the good fortune to touch bases with Ted Neward, Java/.NET author, blogger and consultant. Ted was a regular blogger on our 2007 TSS Interoperability blog, and recently penned a piece for SearchSOA.com on Android development issues.
We asked him about possible Java Virtual Machine (JVM) futures with Oracle now at the Java helm. Oracle’s has sued Google over that company’s reworking of the JVM, and this has put Google’s Android effort in an edgy position. Oracle has said it will continue to promote the idea of multiple languages on the JVM, but will this actually be the case? Continued »
The current state of cloud and API standards is almost an exact match for early SOA and Web services standards, and we expect the standards movement will follow a very similar trend. Hopefully, the cloud standards groups will stand a better chance by learning from the mistakes and successes of the Web services standards.
The discussion of cloud standards at Cloud Camp Boston started by asking the question “What do we want to standardize?” As we looked at standards we found that there are three attributes of apparent concern. These include “API lock-in” (a similar concept to vendor lock-in), migration issues, and the richness or functionality of an API.
One interesting problem with setting standards (For APIs and services both) is the granularity of the work you’re standardizing. Some APIs have a very limited scope and effect only a single application with a single purpose. Others address a broad range of applications with any number of different purposes.
There was a time when EAI was the anti-thesis of SOA, but Enterprise Application Integration (EAI) is making a bit of a comeback within the SOA firmament. The fact is that it never really went away.
Back in the day people discovered EAI handled pesky real-world problems. You had a (fill-in-the-blank) workstation or what have you in the corner and you needed to connect it to (fill-in-the-blank) process or what have you in the back room … and quickly. A programmer would write to the two APIs and then labor the rest of his or her career maintaining the point-to-point solution. Continued »
The growth of Web-connected systems tapping into back-ends has led to a proliferation of services. The proliferation can lead to increased systems’ loads. That expansion has led development shops to place more emphasis than ever on test and performance tools.
Such an apparent case of ”if you build it, they will come” is described by Sergey Sadovnichiy, manager for enterprise solutions at a large Canadian financial concern.
“What was happening was that services, when they were originally built, were few in number and typically had one consumer. Now the number of consumers has gone up dramatically, as well as the number of Web services themselves, and the complexity of the services has risen,” said Sadovnichiy. These are usually large applications, linking enterprise back-ends to the Web.
To deal with the increased volume and complexity, Sadovnichiy and his team have turned to SOAPSonar tools from Crosscheck Networks Inc.
“We do regression tests of each service from the point of view of each consumer type. We now have automated scripts for major consumers,” he said, adding that the scripts can quickly adapt to each use case.
“A Web service may have, for example, 350 elements. But every user will not use all the elements. In each case we can use a different set of scripts.”
Sadovnichiy said SOAPSonar is used for endurance testing and performance testing, along with regression testing. He also sees 100% test coverage, versus earlier scenarios that were risk-based test schemes covering not more than 20% of code.
Crosscheck CEO Mamoon Yunus said the industry has reached an inflection point in terms of services. “Services are getting like Web sites in terms of traffics. There are more trading partners talking to more systems,” he said.
Meanwhile, more able and interactive front-ends are creating more traffic. These RESTful elements do not directly employ XML or SOAP. Crosscheck tools measure JSON and JQuery REST element performance along with traditional SOAP and XML performance.
“People are using more widgets – AJAX widgets, JQuery widgets. From the browser now you hit these services directly. It is not application-to-application anymore as XML, SOAP and Web services were at first. They were more a classic “machine-to-machine” thing. Now, it is “portal-to-apps. The services now are portal driven.”
Yunus said Crosscheck has just released SOAPSonar 6.0. It allows emulation of a virtually unlimited number of concurrent users, and supports demographically disparate loading agents for cloud computing needs.
OSGi is poised to provide a service platform extensive enough to provide ubiquitous modularity – but effectively creating OSGi bundles is still difficult. The Nimble Distribution seeks to address this and related issues. Paremus, an OSGi based private cloud computing provider, and Makewave, the company behind the difficult-to-pronounce Knopflerfish OSGi Service Platform, have teamed up to create and support the new software distribution. The companies suggest their service platform can boost adoption of OSGi in a way similar to Linux as commercially supported “Linux stacks” were introduced. The initial release of the Nimble Distribution includes Paremus OSGi Shell (Posh) – a Unix-like interactive shell and scripting environment, as well as Nimble Resolver – the engine of the Nimble Distribution.
By Kathleen Kriz
Modern modeling languages are constantly developing and changing – this includes the most prominent, the Unified Modeling Language (UML). A 2.3 update to UML is supported by training and new tools from vendor No Magic, Inc.
Gary Duncanson, President and CEO of No Magic, said UML is a foundation to modern software development.
“UML is a basic knowledge that every architect out there must have,” said Duncanson. “You can’t claim to be an enterprise architect, a system engineer, a software developer that uses model-driven architecture (MDA).”
“UML is the gateway to all the other related specs, and all these other profiles are built on top of UML whether it’s for a system on a chip to system engineering to enterprise application integration, all those things are built on top of models, and the basic modeling element is UML,” he said.
Clarence Moreland, COO of No Magic, said UML 2.0 improves on predecessors.
“UML 1 to 1.5 didn’t fit the bill because there wasn’t enough granularity,” said Moreland. “The notation, the syntax of UML didn’t map at a low enough granularity to the syntax of the object-oriented programming languages it was designed to support code generation in.”
UML 2.0 is intended to address syntactic and semantic mismatches between object-oriented programming languages and UML, and will also broaden its applicability when it comes to expanding use from lower level to higher lever software engineering.
Yet, the primary reason UML 2.0 was created was to support model-driven architecture.
“A big driver for UML 2.0 was to be able to support OMG’s model-driven architecture initiative,” said Moreland. “The existing specification didn’t have the semantic richness necessary to support MDA so that was the primary driver.”
Older versions of UML are still being used, and according to Moreland, all versions of UML are backwards compatible, meaning it is possible to support UML 2.3 with UML 1.5.
One of the most prevalent concerns with UML among users is redundancy in the language.
“The biggest problem now is redundancy and also the complexity of the language as it grows to support broader applicability,” said Moreland. “But it is a general purpose modeling language so that’s given rise to domain-specific languages which are for the most part narrower, specialized versions of the UML.”
No Magic is also offering a free training course on UML 2.0 to help people to get trained and up to speed on modeling and on UML in particular, said Duncanson.
As Doug Crockford created JSON it became something of an antidote to XML. This was bound to happen, because the issues developers had with XML were so plentiful. JSON, of course, with an API that fit on a business card, was more than a counter-statement. It was a big success in the making. Twitter recently dropped XML from its API, and this caused a few ripples in the XML/JSON blogosphere. Check this bit on XML versus the Web from Ajaxian.
When you wrap up increasingly sophisticated components to run in specific environments, the complicated hand-crafted scripting can become a burden. With this in mind, Netherlands-based XebiaLabs has created what it calls ‘deployment automation’ tools aimed at handling Java and related middleware.
Deployit integrates with build frameworks like Maven, continuous integration tools like Hudson and Bamboo, as well as with familiar CMDBs. Many tools like this are associated with Agile development, but successful rapid Agile development methods can break down if middleware deployment becomes a bottleneck, said Andrew Phillips, Vice President of Product Development at XebiaLabs.
Cost is an issue too. Often these days, high salaried developers end up tasked to do day-to-day deployment for application servers, ESBs, message queues and the like.
“The situation with Continuous Integration tools is that 97% of code gets tested every day,” Phillips said. “But then the stuff sits in a repository somewhere. You need Continuous Deployment too.”
Phillips said XebiaLabs’ Deployit software uses a Unified Deployment model to ensure that deployments across different types of middleware are done consistently.
The software works through a graphical interface. “You take your deployment package and you drag it onto an environment,” he said.
With an ESB or portal that people have developed in a staging environment, the tools can extract and transform the deployment package so it can run in a different environment, according to Phillips. The software is described as ‘agentless’ and includes interfaces for tweaking deployments.