Architecture definition

While reading some materials a few days ago, I ran over a cool definition of IT architecture, and I thought about sharing it with you.  This is because in the past I encountered (and witnessed) difficulties while attempting to define it in a clear, concise manner.  So here it goes:

Architecture

1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

Have fun :)

IBM DB2 Replication

We recently had an architectural situation/problem to sove and that was to find a way to replicate Databases belonging to different system components between themselves, and more, to replicate all this data to an ODS belonging to our system DWH.

So I have been involved lately with looking at how we can set up a replication between different database instances we have in our solution.  A strong candidate, given our requirements was DB2 SQL Replication.

We found out that DB2 10.5 has strong capabilities in this regard.  One could set up a two way replication between two different database instances installed on two physically separate machines, even with connection limitations in place - I.e. One instance can not connect to the other.  Furthermore, the two way replication can even be configured on the same table, with filtering in place.  This means that for instance, rows matching a certain filtering criteria can be replicated from the instance A to instance B, while rows matching a different criteria can be replicated from instance B to instance A, and all of this happens with the same database table.

The connection limitation can be overcome by configuring the replication agent - that means to have these agents run on the machines that can physically connect to the other machines belonging to the system in question.

The DB2 SQL Replication can work almost instantaneously, replicating the data within a second or two timeframe.

IBM Power Hardware

Hi again :)

I am currently doing architecture related work on a solution that is based on IBM Power hardware and IBM software.

In order to shed some light on the situation, I was thinking to post a few lines on the advantages/disadvantages of IBM Power based hardware versus x86 hardware in general.

There are only three processors left in the market for mission-critical applications. The Intel x86 processor dominates mid-range and small servers, desktops, laptops and notebooks. The IBM mainframe zEC12 processor still dominates extreme workloads for data processing. And the IBM Power processor, which has taken over Unix workloads previously dominated by Sun, HP and other fallen Unix leaders.

For the general market, small business and departmental applications, the choice boils down to Intel x86 or Power.

Comparing the two using enterprise workloads will demonstrate a significant advantage for Power in data workloads such as databases, data warehouses, data transaction processing, data encryption/compression, and certainly in high-performance computing, which most in business think of as analytics.

The IBM Power hardware has an open architecture, while employing RISC based processors.  With Capacity on Demand, Hot-Node Add and Active Memory Expansion—Power Systems enterprise servers ensure you can keep your most important applications available, even as you add capacity to handle new business demands.  Power Systems are also optimized with the ability to securely run multiple applications on AIX, IBM i and Linux operating systems on a single server—so you can manage fewer systems with lower cost and higher utilization.

They are made for running Cloud workloads - the ideal Cloud infrastructure.  A couple of the most advantages delivered by Power systems:
- Exceptional reliability, availability and serviceability (RAS) – and performance. In Power Systems mid-range and high-end systems, we see mean time between failures in the range of 70 to 100 years. This equates to 99.997 percent availability. Power Systems also have features to help manage virtual machine availability and elasticity such as Live Partition Mobility and dynamic resource allocation.
- Leadership virtualization. Power Systems with PowerVM have one of the industries most resilient and flexible hypervisors, supporting virtual machines (VMs) running in as small as one-twentieth of a core or up to 256 cores. PowerVM provides exceptional VM isolation. With the statistical multiplexing on the high-end systems, Power is optimized to run a large number of workloads per server with system utilization in the 70 to 80 percent range.

So what kind of clients are they aimed to?   The power systems are aimed at large enterprises, with stringent needs for reliability, uptime, processing and others.  Although in recent past, they have been also aimed to midsize clients.

In conclusion one could say that while the IBM Power systems are significantly more expensive than x86 based hardware, in the long run, the operational cost savings, as well as superior reliability, serviceability and reliability make them a great choice for enterprises.

Celebrating Bluemix 

As you might know, Bluemix is the new PaaS offering from IBM, due for release in the beginning of July 2014.  It builds on Cloud Foundry Open Source PaaS from Pivotal, and also adds a plethora of new services (mostly IBM software, but also community and third party based), DevOps integration, Web interfaces and support for other Software Defined Environment offerings such as Softlayer.

During the last couple of weeks, I helped organize a Bluemix event at IBM, where together with a couple of other colleagues we held presentations and organized a JAM event with prizes.   We had management support, and managed to secure substantial prizes of around $2000 in value.

We were happy to see that this event sparkled interest and enthusiasm among the participants, and that even if organizing such events seemed hard at the beginning, the feeling that we had afterwards was more than worth the effort.

We plan to hold additional cloud based meetups in the future, touching specific cloud areas such as Big Data, Internet of Things, Mobile and others.

With this occasion, I held a presentation on the business objectives and gains that the new IBM PaaS offering brings on the time to value and cost reductions areas.

I also briefly touched on the "Composable Business" "Holy Graal" objective that the IT strives to attain in order to support the businesses in their course changes - so that they adapt to the market conditions.

Currently, the IT departments are taking months/years to build and provision applications aimed at supporting the new business objectives.  This of course results in rather large time to value and costs for the businesses themselves.  While this is not necessarily bad, it can certainly be improved.   There were also attempts to improve these operational parameters in the past - with switches from Waterfall development styles/processes to more agile ones.  Significant gains have been experienced.   However, this could be further improved through employing new tooling and approaches that would help IT even further bridge the gap to time to value and cost reductions the businesses seek.

The new PaaS offering from IBM is supposed to enable the "API Economy" - so that building new services, applications and reusing the existing ones is going to be very easy.  Interconnecting with Cloud APIs residing on other clouds, integrations with legacy applications and services residing on legacy enterprise environments - all should become straightforward.

As the developers, companies, ISVs are going to construct these building blocks, the ITs will be able to leverage them in order to "stitch together" mobile, and cloud applications in record times - therefore making use of the "composable business" pieces.   The time to value and costs will go down even more, and IT will be able to support the business direction changes quicky - enabling them to cash in on the market trends with much more agility.

I foresee that in the coming years the PaaS offerings from ISVs - including IBM - will mature, and that this DevOps in Cloud model will extend even more.  By then, the composable services will grow in size and number, enabling the API Economy and effectively allowing IT departments to use the "composable business" approach when developing new features and applications.

RUP based processes and technical solution proposals

Hello :)

I decided today - since I have a little time - to write about the importance of following well defined and established processes when defining technical solutions for the clients.

Coincidentally, I have been involved recently in give back activities to the Architecture Profession within the company I work for.  In essence, it is a program where a selected group of people act as SME/Chief Architects for the participants (the assigned Solution Architects responsible for technical solution creation), guiding them through the process of delivering an architectural solution to a given client problem.  The purpose of the program is to help the participants gain real world experience through means of applying the theoretical knowledge they gained while following Architecture courses, thus acquiring the skill set required to successfully deliver architectural solutions on their own.

In short - since this kind of work takes place internally at my company therefore I won't give a lot of details - they need to do the selection of a delivery process from the RUP based framework we have in place, customize it based on the project conditions (and create work breakdown structure) , and then proceed to follow it by creating the artifacts that describe the solution.  All this effort would take place under our supervision as Chief Architects.

This exercise described above, reminded me of the importance of following these delivery processes while creating the technical solutions proposals for the clients.

For instance, we would need to organize ourselves and decide to follow the TSD delivery processes while working on the technical solution proposals; employ AD 2.0 for example while executing the projects, once the contract is secured; and do TDAs each step of the way (for technical solution proposal, as well as for the delivery part).

Of course, in order to be able to achieve all that we would need structural organizational changes to support these activities within our center, we would have to train architects, teach the method, employ technical solution managers.

But the flip side of all that is that we would gain the ability at an organizational level be able to respond to these kind of opportunities in a much coherent way, and therefore increase our changes as an organization to win new contracts - and equally important, deliver them successfully.

Future for DevOps

I thought I would share a few words about DevOps.  As we all know, DevOps is a crossover between Development and Operations.  It's about the development, collaboration and continuous integration, deployment, monitoring of applications, which are common activities that usually take place in an IT project.

And the future of these activities is, you guessed it: in the Cloud :).  It looks like not only the applications are moving to the Cloud, but also the development and deployment activities.

IBM is already working on an array of tools in this area, aimed at covering the development, collaboration and deployment of software and applications.  The codename is BlueMix (www.ibm.com/bluemix) and it will make it much easier to deploy your code in the Cloud.  It also has tight integration with JazzHub for the development life cycle, including software development processes.

BlueMix will offer features such as Application Compositions Environments for creation and mgmt of services, Runtimes and Frameworks support, Middleware Services. Operational and Application services.

More specifically, some features are listed below:

• Runtimes such as Liberty, Node.js, Ruby; 
• DevOps such as Monitoring and Analytics, Git Hosting, Deployment Automation, IDE of choice (even web based, in the same way MS offers Azure Visual Studio); 
• Data Mgmt Services such as SQL & JSON databases, MapReduce; 
• Mobile Services: Push, CloudCode, Mobile app mgmt
• Web application services such as Data & Session cache, elastic MQ, SSO, Log analysis and more.

In conclusion, with BlueMix in the Cloud you will be able to run your apps, develop through JazzHub integration, use provided APIs and Services to help jump start your development, use Cloud integration features to connect to on premises systems, or to other public and private Clouds, or expose your own API.  Or use SaaS SDKs.

So why would we need BlueMix over the current Cloud development PaaS offerings, including application servers, databases webservers and so on?
-- Because it will make it much easier to connect to other applications to share, sync, and manage data through a common Data SDK, do API Integration (i.e. tap into SaaS), do Mobile app development through the provided support, setting up a productive development  environment, do monitoring - or run the code on the runtime of your choice.

In conclusion, soon you will be able to do development, collaboration, reuse and connect to other services and use runtime environments of your choice - all in the Cloud.  You will be able to focus more on building business applications thus shortening your time to market, and focus less on setting up your development, testing and production environments ;)

A new era is upon us: Welcome to the new IBM Cloud Development Platform!

Java Exceptions Management, stacktrace logging and checked versus unchecked

This subject seems to be rather straightforward, correct? :)

I have been involved during the last weeks in situations connected to this subject, and I thought I would share my thoughts on the matter.

At the first sight, one might think that programming around java exceptions could be considered tedious, since you more or less have to handle them or delegate their handling to the calling software layers.

I would think otherwise.  I am of the opinion that the Java exceptions have been designed well originally.  While slightly verbose, their proper handling could greatly ease the maintenance, bug finding and monitoring of java programs.

I have experienced this first hand;  while working with software written in such a way that prevented proper management and logging of java exceptions, I found that it is much harder to find the errors in the programs written by others - without knowing the code base, it was difficult to fix bugs or alter the existing code - I often had to revert to old style debugging.  It shouldn't be that difficult - one look on the stacktrace usually should be enough to understand the situation.

On the checked versus unchecked exceptions subject.   I found that it usually is difficult to predict _many_ of the situations that might appear while the program is running, and this is due to the inherent complexities of the conditions and situations that might appear; For this reason alone, I rather prefer to use checked exceptions as much as possible, that could be handled in a way during the program execution. This approach usually allows the program to recover from additional previously unconsidered situations, possibly with the user help.

One example is the NullPointerException:  while unchecked, it might appear in many situations.  Some of them, usually, could be corrected by the user itself, so it might be worth giving the user a chance to do so.  For example, in case of missing (config) files and others.   Therefore, it might be worth handling this exception in some cases within the java program itself, possibly by employing the usage of checked exceptions instead.