my 2020 focus area(s)

Past years with my blogging breakup, I went through some transformations. One is age (uh, he passed 40 ! ... he must be expensive ! ... no he's not).  The second is that I realized that I'll be continuously learning for the rest of my career, and that's a given. The third is that my daughter will be 18 this year, so it's time for daddy to get back to writing some potentially cool stuff. Or not, that remains to be seen.

With a new assignment starting at the beginning of the year (pre-pandemic ... :facepalm:), I am returning to the role of Integration Architect - the formal name  is some leadership role part of a leadership team :)

I am not ashamed to admit:  I don't know everything there is to know. But right now I am focusing on some Microsoft technologies. Yes, that Microsoft :) ... well, time will tell if they're trustworthy of the FOSS community attention (don't think it will ever be love, there's no such thing in open-source). They grabbed github, they appear to have changed their mindset. 

So here's my focus areas for this year: ADO, ADF, Spark, Scala, Python, HDFS, ADLS2. By focus I mean learning, we're ok here, right ? Some I knew, most I did not. And yes, I will attempt to be certified by Microsoft, once that I can get to their learning testing centers (because pandemic restrictions, we're all WFH, and I assume all their testing centers are pretty closed). 

Ha, fun times ahead.

Application development and deployment target.

Here's an exercise starting while laying on the beach totally disconnected. Yes WiFi does not work, data in roaming too expensive.

Funcky idea popped up:

I want to find examples of apps which cover the following basic set of deployment targets:

1. mobile: Android / iOS, both mobile/tablets. Won't look for web/hybrid/native variants, just for functionality to work unde mobile umbrella, be it smartphone/tablets.
2. web. Browsers, plain and simple (FF and Chrome, cross compatibility etc, frameworks these days make it easier)
3. desktop. Here I see coverage of Linux, Mac and Windows.

edit: One could argue that web and desktop are pretty much the same. The contra-argument I'm making is the sync apps for clouds, for instance Box and Gdrive. These do not run in browsers, but on desktop. So keeping the two separate, with maybe countless of other examples. Browsers are not always desktop similar.

The three targets would then translate into the following list of sub-targets:

1. Android - smartphone
2. Android - tablet
3. iOS - smartphone
4. iOS - tablet
5. web (let's assume Firefox and Chrome as one, who cares ;) 
6. Linux - Ubuntu / Fedora ... here I'm missing technology to suggest one that works across distributions...except Java ... ha
7. Mac OS X Yosemite ... again newbie, not sure what to pick
8. Windows .... 10 ? not quite, let's just say 7 / 8.

And so I'm challenging my readers to give me examples of applications running on the 8 targets above.

What on earth is doing a startup coming with a brand new idea for a wonderful application (either commercial or open-source) if they cannot accomodate this list. You'd answer: they do what they can. Ok, good enough, however, myself as a consumer, I already use all those targets, in one way or another. And I'm starting to feel the need when looking to a new app and ask: ok, this app fails which bullet ? Then ... do I need it ?

And guess what, while writing this, it suddenly popped to me one example. Just one, for now: IBM Notes. Yes, good old Notes, is answering to the three "domains" above, here:

- mobile. Android/iOS, checked.
- web. checked, both Traveler / Verse.
- desktop. Mac checked, Linux checked, Windows checked.

Well, opened to more suggestions, hit me please.

RTC and RRC

Just spotted an excellent article about Rational Team Concert (RTC) and Rational Requirements Composer (RRC), which actually fills a gap to my knowledge.

Article is on devworks, a favorite place to look for interesting stuff. It touches a few points, go have a read.

From some time I've been using RTC quite extensively, handling the process / workitems definition, together with its source control system. The point is that the more I know, the more I do understand that a tool isn't enough.

I also came to understand that while tooling isn't enough, adoption is what counts in the evolution of the project.

As the PM or Architect, you can define for the project:

- template for deliverables
- process and roles in project area
- source control process for streams/components
- development conventions
- architectural decisions
- (...) add here countless items from any imaginable methodology

If your team does not adopt above items (which btw, should be tailored to suit the project needs), you're doomed to fail.

What a great PM/Architect does (I haven't seen many ... ), is convince the team that their additional work (like filling fields in workitems, write according to templates) is needed because .... (give the reasoning). And if you manage to convince that stubborn smart team member so that he freely complies and adopt your things, you're on the right track.

Development in small team of friends is one thing. Development in international teams of people only familiar to eachother over the phone, is another.

met a Big Data ironman

Last week (6th Apr.) I had the pleasure of watching Jeff Jonas live, on stage, speaking about the things he does.

I'm trying to raise awarness, since this fella speaks simple and straighforward even for non-tech people. Big Data is not my domain and I personally think it's gonna take years for certain parts of Europe and their businesses to even start thinking on that. 

However, the things Jeff's addressing are fascinating, have a look on the following links:

http://www.research.ibm.com/theworldin2050/bios-Jonas.shtml

http://techcrunch.com/2010/10/27/big-data/

http://gigaom.com/2010/10/11/jeff-jonas-big-data/

Enterprise Architecture (EA) view from an IT Architect

This post wants to share with you my take on EA, after attending a course led by some smart people. I won't share their names without permission, but they're smart, that I can tell you.

Note: this work may change over time as I read more. I actually didn't had the time to read topics/articles on EA before attending this class. This is why I might be biased or even wrong. Feel free to comment or send me emails, critics make me better.

Here we go:

1. Who is EA for:
- those companies who lost track of applications and systems
- those companies having no or sparse governance
- those companies having stakeholders which feel like wanna change things: either by their IT or their business
- those companies loosing money, market share or customers. So, all of us ? The answer is yes.

2. What EA is NOT:
- it's NOT a miracle, but a discipline / practice of doing things with more rigorous approach.
- it's NOT a method, but a journey.
- it does NOT starts in point A and finish in point B, its an ongoing effort which ends with the business itself.

because:

1. EA tries to get the business near to the practices and methods of software development, by means of change management, governance and agility.
2. EA is trying to become the link coupling together the business (your business, any type of it) and the IT.
3. EA discipline is trying to find out what you're doing wrong so you might start change things. When you start and how you start makes the difference between bad and good consultants (either yours or your collaborators/partners).

What you need:

1. an understanding that you're doing something wrong. This requires brains, only smart people admit they're wrong.
2. an understanding that IT might not be the part that needs to change, but perhaps your organization and/or business processes need to change first.
3. good consultants on doing things technically and/or knowing your industry. These are rather hard to get and usualy speak beautiful words, however, they're diplomats enough to they tell the truth in your face. If you're also smart, you get the message and you'll also recognize them. I also start to recognize BSers from professionals, so wouldn't be that hard, I guess :)
4. stakeholders willing to change things. This might be the toughest part. On the saying that "if it works, don't break it", resistance to change is usually what stops organizations to pursue such changes.

With these things out in the air, next time you receive a mail with signature from an "enterprise architect" you'll know something is wrong. Because EA is about the change we perform each day. Hell, I am as well practicing EA with some of my customers. I will never be an enterprise architect, there is no such profession, as far as I consider. There are good or bad consultants, that I know.

projects failing. lessons learned.

Having been involved in several engagements past months, I took some lessons from what I consider to be good technology with bad implementations. These were not necessarily failed projects but I had a feeling of unaccomplished work. And this is because I am usually passionate about the technology I work with and I want to drag people with me, which didn't happened. Why I had these mixed feelings and the lessons I draw:

Lesson 1. Project Scope. Define the scope of your project and DO NOT cease to pressures by either your sales or customer. DO NOT accept further changes in scope without estimating impact and effort implied. Otherwise you will usually end up with more effort spend, which will translate into business issues on your side.

Lesson 2. Team skills. This is a point where the project itself needs to be planned around building or gathering the proper technical skills. Without that, I learned the hard way that nobody on customer side will ever be able to takeover your work. On the other side, not having the proper team skills upfront will again end up with more effort spend on the project.

Lesson 3. Project Setup itself. If you're working with people not willing to listen or not able to understand what you're saying, project will not end up in good conditions.

Lesson 4. I give pretty good estimates on activities part of different WBS. This last one is for me to compensate the above three points :)

IT Architecture: my understanding

All I can say is that IT Architecture is an interesting job. It is a rather new profession, I think started to be defined in 2003, http://www.opengroup.org/itac/faq.html).

It should be the ultimate level of technical excellence one could achieve, understanding technology, systems, processes and businesses. On the other hand, the IT Architect should embrace skills from different areas, not only technical.

An IT Architect performs consulting, PR, marketing and so on, depending on whom he needs to convince or what tasks he has to perform in order to demonstrate business value of its proposed IT architecture.

And, finally, the primary task of an IT Architect is to know how to work with the PM and customer in order to organize the project, once it's sold. Tasks,roles,skills first, then help PM to define the project plan and so on.

But, I've developed a more simple vision, in practice. For me, IT Architects belongs to one of two categories:

1. IT Architect. A professional as described above. Rare species, you won't find many. This is the ultimate fellow which knows what is speaking about because he/she was there, first of all. In development, solving problems with technology. Drawing use-cases, modeling, working with systems, whatever. He/she was there more than writing lines of codes or modeling. Gradually the understanding of the domain grew more than sometimes performing boring tasks (refactoring for example, or adjusting requirement documents).

2. PowerPoint IT Architect. This is a more common individual, which draws slides fast and talk too much without actually getting something done in practice. Everything is simple in front of the customer, in order to sell an idea which might prove a nightmare when delivery approaches.