Our Blog

By Pete Conrad,                                                                                                                                       Director – Enterprise 2.0 Practice,  Bluenog Solutions Group

Earlier this year, Apache Beehive went into retirement in the Apache Attic.   Apache Beehive, with its roots in BEA as Netui, Java Page Flows, and other WebLogic Workshop components, was a great idea in its day. While its transition from BEA to Apache was marketed as support for the Open Source community, it never really turned the corner and gained interest outside of core WebLogic supporters.

Beehive’s retirement has become more interesting since Oracle’s purchase of BEA and the technology consolidations that have removed  any remaining support for Beehive.

The challenge is now to help WebLogic developers, architects, and owners that have built skill sets and systems with Beehive to continue to evolve their solutions, update their applications and skills, while protecting their investments.

During the time of Beehive’s decline, the open source Spring Framework has grown to be a juggernaut. The Spring Framework and Spring Webflows are of tremendous value when refactoring WebLogic Portal applications and retooling development teams for the future.

There are several compelling technical and business reasons to consider Spring:

• As a leading open source project, it has strong community support continuing to develop, improve, and extend its framework.
• Developers who are looking to improve their marketable skill set will be more satisfied with leveraging Spring and the further advanced developers should be available when new team members are needed.
• As an open source project it provides standard open means to build solutions that can operate on any leading commercial or open source Java application server, protecting applications from vendor lock in.

At Bluenog, we work with our clients to develop both Commercial portal solutions as well as portals based on Bluenog ICE. Spring provides the tools to rapidly build stronger, more flexible portal solutions regardless of the portal platform.

By Tom Hegadorn                                                                                                                                   Director – Integration / SOA Practice                                                                                                        Bluenog Solutions Group

If you’re like many technology professionals, security is often an afterthought in your implementations. With the usual pressure to meet deadlines for critical business functionality in often unreasonably short time-frames while still providing the requisite quality and performance characteristics,  who has time to devote to a thorough treatment of security? Add to that the usual lack of formally defined policies and requirements in the areas of information security, and it’s no wonder that implementation of security within applications is often an afterthought at best.

Bluenog Solutions Group has seen a similar pattern among clients who’ve adopted Service Oriented Architecture (SOA) within their organizations. In the rush to deliver on the promised benefits of SOA, organizations have gone ahead with implementation of services and adoption of key pieces of SOA-enabled middleware such as an Enterprise Service Bus (ESB) with little thought for how they would secure the newly adopted infrastructure. With increased regulatory compliance requirements in the banking and pharmaceutical industries, we’re finding clients are now having to go back and re-factor their SOA implementations to make sure that the services are secured appropriately. I’ve recently delivered several such engagements to help clients rationalize their SOA security strategy.

Beyond the typical approaches for network-based security and hardening of machines at the operating system level, what is the best way to begin the task of securing a service-based implementation? This blog represents the start of a short series of entries that will describe a practical way to get started with SOA security.

To whet your appetite for what is to follow, it helps to start with basic requirements in the areas of authentication, authorization and confidentiality. Addressing these key areas will go a long way toward identifying the specifics of securing your SOA infrastructure. Most security requirements fall into one of these three areas. Another source of input for establishing your basic requirements is your internal legal team or corporate security team. These functions are usually aware of compliance issues specific to your business and any policies that have been developed to try to mitigate the risk associated with system vulnerabilities.

Once you have developed a core set of requirements, you will be in a better position to assess specific solution approaches to address those security requirements. Depending on the SOA infrastructure you’ve adopted and the skill set of your technical team certain solutions may be preferable from an implementation perspective. We will look at some of the specific solution approaches in the next installment of this series. Stay tuned for more detailed information about specific approaches.

John Porter - Bluenog Practice Director

Effective dashboard design should be approached with many of the same principles as good website design. An effective website delivers the right information to targeted groups of users with minimal effort on their part. The design of a good reporting dashboard seeks to hit a similar target. A dashboard serving the CEO of an enterprise will look and behave very differently from a dashboard meant to serve only a specific department within the company. Therefore the design of a dashboard for an executive measuring company performance against a set of strategic metrics will offer a different set of functionality and level of granularity than an operational dashboard measuring the real-time flow of call center metrics to a group supervisor. It is critical to provide the appropriate level of data abstraction based up on the role of the audience.

While well designed dashboards hold the potential to help executives, managers and front line workers make sense of complex operational data, they only tell part of the story. The complete picture can only be obtained once contextual, unstructured information is added to the mix.

Portal technology combined with the right level of reporting and analytics is an ideal pairing with which to meet these needs. Why couple a portal with reporting technology? True portal technology can tie the benefits of personalization, single sign-on and aggregation of unstructured content into the world of the reporting dashboard. Imagine being able to access documents, presentations and applications that all contain information related to the data displayed in the dashboard. A properly implemented portal knows the role of the user and their area of responsibility. It can combine this information along with dashboard and content metadata to provide a truly comprehensive view of organizational or departmental health. This design presents a very powerful mechanism for turning data into knowledge.

The operational insights gained by deploying hierarchical dashboards across multiple levels of the organization is further enhanced by transforming the information they provide into actionable knowledge. This can be accomplished in part by adding drill-down capabilities to ever more granular levels of detail. Actionable insight is ultimately achieved by linking contextually relevant documents and unstructured data alongside the dashboard display and providing a means to securely communicate and collaborate on findings between team members.

Portal technology coupled with a well thought out meta-data strategy is uniquely suited to take dashboard benefits to the next level. In upcoming posts I'll build on these concepts driving a comprehensive portal and reporting strategy.